[campd oit edu: Re: [Gnome-devtools] Handling External Dependencies]

[Martijn van Beers <martijn earthling net>]

----- Forwarded message from Dave Camp <campd oit edu> -----

To: Martijn van Beers <martijn earthling net>
Subject: Re: [Gnome-devtools] Handling External Dependencies
From: Dave Camp <campd oit edu>
Date: 13 Apr 2000 14:27:04 -0700
In-Reply-To: Martijn van Beers's message of "Thu, 13 Apr 2000 23:03:14 +0200"
X-Mailer: Gnus v5.7/Emacs 20.5

Martijn van Beers <martijn earthling net> writes:

> > 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.

The point is, the content changes based on the backend used.  That is
the problem I'm trying to solve here.  If you think it should be 
inverted, so that instead of...

<backend type="auto*">
  <cflags>...</cflags>
  <ldflags>...</ldflags>
</backend>
<backend type="other">
  ...
</backend>

...you have...

<cflags>
  <backend type="auto*">$(BONOBO_CFLAGS)</backend>
  <backend type="other">...</backend>
</cflags>
<ldflags>
  ...
</ldflags>

...then that is possible.  But why not keep the first structure, and let
a backend decide the best structure and terminology for itself?

> 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 think the problem is that they look superficially the same (you pass
compiler and linker options), but the devil is in the details.  The
command lines you pass are completely dependent on what the backend
is.  The way you determine these command lines is different.  

For example, you have an add_cflag() method in you Target interface
(actually you don't but I assume it is supposed to be there).  That is
fine.  But the problem I am trying to solve is not "Should we use
command line options?", but "What command line options do you want to
put in there?".  

There are a couple of ways to handle this.  One is to let the user
enter his cflags and ldflags directly for everything.  That is the way
your method supports.  The IDE can't provide any sort of help with
this, because there is no way to divine what sort of thing can go into
the cflags for a given backend without additional information.  

Then you have the autoconf checks that are needed to support these
cflags and ldflags.  You have no interface for adding these to the
project as it stands.  To some extent, it doesn't belong in
GBF::Project, because that is an autoconf-ism, plain and simple.  You
could debate that compiler flags and ldflags are universal (in fact,
I'd agree with you).  But autoconf checks are strictly
backend-dependent, yet are a vital part of dealing with auto* projects.

I'm trying to provide clues for the IDE and backend to intelligently
deal with these issues without tying itself to a single backend's
representation.

> 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.

I agree that the concepts of targets, cflags and ldflags is a good
level of abstraction.  I'm not trying to debate that.  I am just
saying that every project type has its own little idiosyncrasies in
target dependencies (such as auto* checks) that could be intelligently 
dealt with in a clean manner with dependency descriptions.

> 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.

I'm not trying to deal with different levels of abstraction, I'm
trying to deal with differences in implementation on the same level of
abstraction. 

Cheers,
-dave

----- End forwarded message -----