Re: [Gnome-devtools] Abstracting Build Systems



JP Rosevear <jpr arcavia com> writes:
> source = provider of functionality (even if the functionality is
> internal to the source)
> target = a group of dependent sources that form a user runnable program
> (interpreted or whatever).  May rely on libraries.
> library = external, independent provider of functionality to targets
> project = a group of targets that logically form an association

These seem like fair abstractions.  However, the definition of target
should be changed to something like "a group of dependent sources that
form a final product" -- not all targets are user runnable programs.

> As far as I know, the concepts of sources, targets, projects and
> libraries apply to every build system we've discussed:

Yes, I think most sane build systems use these abstractions.

> The backends know best how to really implement the addition of libraries
> to targets.  However, the discovery of library availability is really
> language dependent (ie. C/C++ libraries can be found with ldd, java ones
> with classpaths, python ones in another way) rather than build system
> dependent.
Quite true.

> So, gnome-build can probably build library lists with dependencies in a
> language specific manner, we'll need to code this but for a lot of key
> languages, this should be fairly straightforward.

I agree that finding the dependencies shouldn't be that tough for most
languages, but mapping these dependencies to something the backend can
use properly might be difficult.

> For auto*, autoc*
> needs to provide a mapping internally from libraries to macros.  If it
> can map this stuff (say -lbonobo to GNOME_BONOBO_CHECKS and BONOBO_LIBS)
> then it should, if it can't it can use a default handler to add -lbonobo
> to LD_FLAGS of the target.  The auto* backend will also need to define
> the languages it can handle and will probably need to handle various
> libraries in different ways.

Herein lies the problem.  Mapping libraries to autoconf checks is a
difficult thing to do.  For example, just inside GNOME:

libxml     -> GNOME_XML_CHECK
gnome-libs -> GNOME_INIT
bonobo     -> AM_PATH_BONOBO

There really isn't a nice way to figure these out.  There are a few
common rules you can check for (AM_PATH_<libname>), but you can't be
sure that every library will use these formats, or that you have found
the correct macro.  There would need to be a way to resolve exceptions 
to these rules (as well as a mechanism for determining if something
fits into the rules in the first place).

I do like the idea of using language-dependent library-locating
routines, we just need to solve some issues for it to work correctly.

Later,
-dave




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]