AW: Re[6]: C/C++ projects don't work for suse 7.2, suse7.3 and upcoming kdevelop 2.0.2

Markus Kuehni markus.kuehni at trilab.ch
Thu Nov 15 09:35:59 UTC 2001


jbb:
> Take a look at jam (http://www.perforce.com/jam/jam.html)
>
> Does this come closer to what you want?

Hmmm... looks like jam uses a database for platform specific rules and
variables. The one thing, I "unconditionally like" about the auto* tools is
the principle of feature tests.

That is they try to find specific files like libs and headers, they try to
compile small test programs etc. each time you execute ./configure.
(foget caching for now)

By probing the specific platform instead of using a database (like jam)
configuration is always up to date and can even adapt to a specific
never-seen-before host setup.

I'm not "The Expert" in these matters but I believe auto* tools can't be
replaced easily both for technical and "political" reasons.

*BUT* IMO one could add another (yes, yet another!) layer of abstraction and
really hide the ugly inner workings of this stuff. At least for a big
percentage of the "stream-linier" projects.

And we must try to shift the platform complexity and configuration into
platform libraries and their setup. This way only the developers of these
libraries got to fight the beast. Developers building on top of these
libraries should be shielded from complex host config through:

- ready-configured installed headers (with all the #defines, typedefs etc.)
- ready-configured lib code (such as replacement API and
conditional/platform specific code)
- higher layer of abstraction

Developers building on top of these libraries should only need to (in their
configuration):

- check for and configure (the version, linkage, etc.) of these libraries
and headers

Libraries such as Qt/KDE, glib/gtk+/gnome, wxWindows, etc. already do that
to an extent (I hope!) and there is room for more.

(Libraries should probably be more modular than the above examples and try
to follow the U*X principle of "one tool, one task").

-- Mark



-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe ťyour-email-addressŤ



More information about the KDevelop-devel mailing list