Re: [Gnome-devtools] Handling External Dependencies

[Martijn van Beers <martijn earthling net>]

On Thu, Apr 13, 2000 at 01:29:50PM -0700, Dave Camp wrote:
> Martijn van Beers <martijn earthling net> writes:
> > On Wed, Apr 12, 2000 at 05:47:04PM -0700, Dave Camp wrote:
> > 
> > > Handling external dependencies is basically backend-dependent.  If we
> > > are using an auto* setup, we're going to handle the dependencies with
> > > autoconf macros, cflags, and ldflags.  If using a java-based backend,
> > > it will deal with CLASSPATHs and .class files. 
> > 
> > I'm not sure if they're really that different. In the end, it all comes
> > down to which compiler flags you give for the compile (and link) stage.
> 
> Depending on the backend, these flags have the potential to be quite
> different.  For example, when using autoconf/automake with proper
> macros, you'll probably use something like $(BONOBO_CFLAGS) and
> $(BONOBO_LIBS) when compiling/linking.  On the other hand, if you're
> working with a different gcc/make-based backend, you'll probably want
> `gnome-config --cflags bonobo` and `gnome-config --libs bonobo`.

that's just the content of them. you still end up with a bunch of
flags to use at compile time and link time for each.

> Java will act differently still.  A java dependency doesn't need
> cflags and ldflags, it simply finds class files on its CLASSPATH.
> However, a dependency for java might want to add something to the
> user's classpath when building and running; this doesn't really fit
> into the category of compiling and linking flags.

I really don't want to go into running, but compiling a .java file is
no different from compiling a .c file. The only difference is you don't
need to link the resulting file, as you have to with C.

You still want to give compiler flags for the java compiler to find
all the dependencies:

   javac -classpath '$CLASSPATH:/opt/wherever/' bleh.java


The point I'm trying to make here is that even though these systems
may look completely different if you look at them superficially, they're
still using the same concepts. If we're wanting to create an interface
that works with several build systems, we'll have to go beyond the
superficial look, and try to find the concepts behind the systems.

I still think my Target interface isn't very auto* dependant, it just
uses the auto* terminology, because that's what I use.

Automake has the most abstracted mechanism of all the build mechanisms
I've seen so far, so I think it is a good starting point. We'll never
be able to work with every build system file in existance as is, since
there's _way_ too many ways to do things with plain make. So, if we
stick to the level of abstraction automake gives us, we can demand of
other build system files that they have this level of abstraction added
too them through an include.

So, instead of supporting:

       foo:      foo1.o  foo2.o
                 $(CC)  -o  $@  foo1.o  foo2.o  $(LDFLAGS)

with imake directly, we demand that build files we support have
a file included that does:

       #define   program_target(program, objlist)        @@\
       program:  objlist                                 @@\
                 $(CC)  -o  $@  objlist  $(LDFLAGS)

so we can parse the:

program_target(foo, foo1.o  foo2.o)

that already looks a lot more like the automake level of abstraction
than that first bit

of course, we really want to do:

program_target(foo, foo1.c, foo2.c)

and have the define be a bit more elaborate. This last bit looks
remarkably like the automake way:

bin_PROGRAMS = foo

foo_SOURCES = foo1.c foo2.c

but with a very different syntax. Unless we try to get every build
system to the same level of abstraction, there's no way we can have
a sane interface that supports all of them.


Martijn