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.
