KDevelop4 BuildManager/BuildTools

[Andreas Pakulat]

On 21.01.07 15:26:42, Alexander Neundorf wrote:
> On Sunday 21 January 2007 14:19, Andreas Pakulat wrote:
> > On 21.01.07 11:46:36, Alexander Neundorf wrote:
> 
> ... snipped everything to which I agree

I do the same :)

> > > For instance what should the user do if he wants to link to some library,
> > > e.g. libxml2.so ?
> >
> > Well, the simple approach to this is to let the user define the library
> > including path and put the proper cmake commands for that. I don't think
> > this is a very good idea.
> 
> What do you mean exactly with "define the library including path" ?

Well, like KDevelop3.4 QMake manager does already, the user specifies a
shared or static lib and the project manager cuts out the path to set
the -L<path> and the library name (cutting out lib<name>.so*) and put
-l<name> into the buildsystem. But as I said this gets dangerous once
the project is spread.

> > > Before I make up ideas how not to do it, I better ask: what's the plan
> > > how this should be done for QMake, CMake, autotools ?
> >
> > Matt has some ideas, but unfortunately didn't write them down or tell
> > us.
> >
> > Thinking out loud: Let the user provide a macro call for finding a
> > specific library (which he needs to implement outside the GUI) and then
> 
> Macro as in CMake macro ?

Yes.

> Problem: it is very unportable, unportable between different Linux 
> installations, and even more unportable between different compilers or OSs

Its even unportable on the same system, as soon as a lib-name change
happens...

> In CMake the script can execute commands, parse their output, do regexps, 
> depending on this add files or libs or whole directories or ...
> The same is true for autotools, not sure about qmake.

QMake can do pretty neat stuff too, but it normally needs a configure
script to setup the base variables and check for libs...

Anyway, I wasn't supposing to provide a GUI to write CMake macros, only
a way to let the user add a library to the given target. So he only has
to write the macro to find the library and set an apropriate variable
(or whatever) and tell the cmake manager that he wants this library
together with a call to this macro in the CMakeLists.txt. Maybe Matt got
better ideas here...

> -and maybe something between the two
> But honestly, if the project is intended to be compiled on more machines than 
> only the box of the developer, than the developer really should care about 
> portability issues, and for this he really should know the buildsystem. 

I completely agree here that this mixed-mode doesn't make too much sense
and I doubt there are users for this...

> Just some thoughts...

As I said, everything I snipped I totally agree :)

Andreas

-- 
Your love life will be... interesting.