Re: [Gnome-devtools] Handling External Dependencies

[Dave Camp <campd oit edu>]

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

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.

> A problem with doing it this way is that the files need to be changed
> everytime someone creates a new backend. Maybe it would be possible
> to keep the files completely generic, and have the backend deduct
> the information on-the-fly

Being too generic creates problems.  Further down in your response you
said "auto-generated UI sucks."  Sucky auto-generated user interfaces
are a subset of the problem created by trying to deduct information 
about a system on-the-fly.  If we do not have per-backend information,
some backend will not get the information it needs, and another will
have to bend over backwards to tailor the information to itself (and
probably won't do a perfect job of it.  For example, a "completely 
generic" implementation could not include information about the 
autoconf macros used to configure the dependency.

The point of this file is to take care of backend-specific
information.  If we can find a good subset of information that can be
effectively shared across backends, then a seperate block of
information about globally useful information would be a good
addition.  But the backend-dependent information is necessary.
 
> > The stuff in the macro-arg area could easily be mapped to an
> > auto-generated UI in the project manager.
> 
> Auto-generated UI sucks.
In most cases, yes.  But consider the situation:

o Most macros have only a few arguments (0-3 in most of the ones I've
  seen).
o These macros are typically either strings, boolean values, or code
  fragments (typically inserted in pass/fail situations).  The UI for
  entering these things will be fairly common between dependencies.

So there are two options:
o Use the information provided by the dependency description to build
  a user interface for configuring it.
o Have each dependency provide its own UI and code for handling its
  UI.  This will add way too much work to creating dependencies
  (dependencies should really be creatable in a few minutes), and will
  also add a great deal of code to the project.  In addition, 95% of
  the supplied UIs will look just like their generated counterparts
  (how many ways are there to have a user enter a boolean value), and
  the other 5% will just be badly designed (there's only one right way
  to have a user enter a boolean value).


Anyway, those are my thoughts.