[Gnome-devtools] Handling External Dependencies

[Dave Camp <campd oit edu>]

I'm reposting this here so we can get some discussion going.  I've
already discussed this a bit with JP and Martijn, and there were some
issues.  I won't bring them up right now, I'll let one of them handle
that. :)

General Stuff
=============

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. 

External dependencies are a somewhat difficult problem even when only
dealing with the auto* framework.  A dependency includes configuration
data (autoconf macros), compiler flags, and linker flags.  It also has
its own set of dependencies.  Each of these things is basically unique
to the dependency, and can't be handled correctly without more
information.  I would assume the same is true of other build systems.

I was thinking that it would be good to have a set of dependency
descriptions that could be used to deal with this problem.  They would
be held in a seperate directory (similar to .gnorba files).  Each
description would have the following basic form (I'm not an expert at
xml formats, I apologize for any glaring errors):

<gbf-dependency name="Bonobo">
  <description>The Bonobo object model</description>

  <dependency name="ORBit"/>
  <dependency name="gnome-libs"/>

  <information backend="autoconf">
    <project-info>
      <!-- per-project autoconf related information -->
    </project-info>
    <target-info>
      <!-- per-target autoconf related info -->
    </target-info>
  </information>

  <!-- any number of different information blocks -->
</gbf-dependency>

Use of this form would allow different libraries to be added to
different backends in a somewhat generic fashion.

Auto* specific information
==========================

With that said, here are my thoughts on the auto*-specific part
of the dependency description.

* Project-level information

The major project-level information for the auto*-specific backend
will be configuration info, particularly autoconf stuff.  This will
consist primarily of two pieces of information:  The necessary
autoconf macros to insert into the project, as well as a regular
expression to match an existing autoconf macro.  For example (this is
a really quick example and could be vastly improved):

<project-info>
  <autoconf-macro>
	<macro>AM_PATH_BONOBO (%minimum-ver)</macro>
	<macro-arg id="minumum-ver" type="string" name="Minimum Version"/>
  </autoconf-macro>
  <autoconf-regex>
	AM_PATH_BONOBO.*$
        <!-- probably need a way to map the regex to the macro-args -->
        <!-- above. -->
  </autoconf-regex>
  <autoconf-regex>
        <!-- there might be more than one form that needs to be 
        <!-- recognized, so there can be multiple regex blocks -->
  </autoconf-regex>
</project-info>

The stuff in the macro-arg area could easily be mapped to an
auto-generated UI in the project manager.

* Target-level information

This would be the stuff to put in cflags, ldadd, and ldflags:

<target-info>
  <cflags>$(BONOBO_CFLAGS)</cflags>
  <ldflags>$(BONOBO_LIBS)</ldflags>
  <!-- etc. -->
</target-info>

As a quick side-note, the following layout would be used for a
basic no-auto* backend:

<project-info/>
<target-info>
  <cflags>`gnome-config --cflags bonobo`</cflags>
  <ldflags>`gnome-config --libs bonobo`</ldflags>
</target-info>

API
===

There are essentially two different APIs that need to be worked out:
The api for accessing the target information in the database, and an
API for attaching dependencies to targets and projects.

* Accessing the database

This would likely be a pretty simple API.  We can discuss this when/if
we decide to go in this direction.  I don't think it's a big deal.

* Attaching dependencies to a target

I would suggest the following methods in the GBF::Target interface:

-----
// Adds an external dependency to the target
// name - The dependency's name (as identified in the description)
// follow_subdependencies - Whether or not to add subdependencies of
//   the dependency to the target.
void add_external_dependency (in string name, 
                              in boolean follow_subdependencies);

// Removes an external dependency from the target
void remove_external_dependency (in string name);

readonly attribute StringList external_dependencies;
-----

Comments appreciated,
-dave