Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Well, configure --help gives me this:

--disable-ada           disable programming language support for Ada
--disable-bash          disable programming language support for bash
--disable-cpp           disable programming language support for C and C++
--disable-fortran       disable programming language support for Fortran
--disable-haskell       disable programming language support for haskell
--disable-java          disable programming language support for Java
--disable-pascal        disable programming language support for Pascal
--disable-perl          disable programming language support for perl
--disable-php           disable programming language support for PHP
--disable-python        disable programming language support for Python
--disable-ruby          disable programming language support for ruby
--disable-sql           disable programming language support for SQL
--disable-antproject    disable build tool support for ant
--disable-autoproject   disable build tool support for autotools
--disable-customproject disable build tool support for custom makefiles
--disable-scriptproject disable build tool support for script
--disable-trollproject  disable build tool support for qmake
--disable-clearcase     disable vcs support for clearcase
--disable-cvs           disable vcs support for cvs
--disable-perforce      disable vcs support for perforce
--disable-subversion    disable vcs support for subversion

So I thought, why don't make use of those options. Furthermore you can see that current ebuild for kdevelop 3.2beta incorrectly sets up python and java (ie. the won't get disabled)

So this is my suggestion for updated IUSE and $makeconf:

IUSE="ada ant automake bash clearcase c custom cvs doc fortran haskell java qmake pascal perl php python perforce ruby script sql svn"


	myconf="$myconf $(use_enable java) $(use_with java java $(java-config --jdk-home))
			$(use_enable python) $(use_with python pythondir /usr/lib/python${PYVER})
			$(use_enable ruby) $(use_enable ant antproject) $(use_enable ada)  $(use_enable bash)
			$(use_enable clearcase) $(use_enable c cpp) $(use_enable cvs) $(use_enable fortran)
			$(use_enable haskell) $(use_enable qmake trollproject) $(use_enable pascal) $(use_enable perl)
			$(use_enable php) $(use_enable perforce) $(use_enable sql) $(use_enable svn subversion)
			$(use_enable scipt scriptproject) $(use_enable custom customproject)
			$(use_enable automake autoproject)"


I compiled kdevelop with -ada -ant -arts +automake -bash +c -clearcase -custom -cvs -debug -doc -fortran -haskell -java +kdeenablefinal -pascal -perforce -perl -php -python -qmake -ruby -script -sql -svn -xinerama

and yes, it compiled nicely (nad faster) and I got what I need: support for c and c++ and no other junk...

If you like my suggestion, I will make a patch and fuirthermore add some descriptive information to the ebuild which explains all the use flags.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Nice find.  I'll look into getting this into portage.

BTW, I am currently browsing the Makefiles of kdevelop and see they haven't
doen the dependencies the smartest way, if I understand correctly.

Eg.: ./lib/cppparser ist built anyway, but it is only used by languages/cpp

same applies to /lib/antlr which is built anyway, but isn't used by all
languages.

So, maybe bug upstream to work out dependencies correctly?

Yeah - I think they'd be especially receptive if you can include a patch to the
configure.in.in files for these features as well.

Uhm, isn't configure.in.in an autogenerated file? I am not an expert on
automake, autoconf 'n' stuff. I thought about explicitly inserting the needed
libs into SUBDIRS in the languages' Makefile.am. this way automake resolves
depencies and I don't have to care. Then I can delete antlr and stuff in
Makefile.am in lib/ and everything should work automagically. Do you think this
is the way to go?

no configure.in.in isn't autogenerated. What's generated is the root
configure.in that se the sum of all the configure.in.in.

I don't know what's the problem, but I can tell you that a fix can involve both
configure.in.in and Automake.am, depending if there's also a configure flag or
check that needs to be changed to make all works or not.

Ok, thanks, after experimenting wiht it, I also had that impression. :) But my
idea seems to work, ie defining the dependency by adding the dependent lib to
SUBDIRS. I even went a step further and it seems to be possible to spilt the
ebuild into a "kdevelop-base" package and a package which builds the language,
project and version management modules - without redundant compiling.

I will ask the kdevelop devs if they are interested in this work and ask them
what would be the best way to do so. (I mostly played around with the
Makefile.am's.) I think it should be possible to implement in such a way that
old behaviour can be chosen or the split one, ie. either compile the base or
the modules.

In kdevelop-3.2.0_rc1, I implemented a good amount of these useflags.
Not _all_, because that seemed to me like pushing it a bit too far, and we
don't really want to have basic features like c/c++ and automake support
disabled by default.
Anyway, kdevelop should be really configurable now.