gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <>
Subject Re: Gump
Date Wed, 03 Mar 2004 08:54:54 GMT

One of the things I have been playing with in the C builder is the idea 
of identifying official releases.

So as an example, xml-security-c depends on Xerces-c and Xalan-c.  So 
for xml-security-c I do three builds :

- Xerces-c cvs, Xalan-C cvs and Xml-security cvs (bleading edge)
- Xerces-c 2.5, Xalan-C 1.7 and Xml-security cvs (current official 
release of Xerces and Xalan combined with xml-security from CVS)
- Xerces-c 2.3, Xalan-C 1.6 and Xml-security cvs (n-1 official release 
against CVS).

For Xerces-c and Xalan c, I keep a compiled copy of the last 2 versions 
(n and n-1) and use LD_LIBRARY_PATH and configure options to compile 
against the correct version.

By only going n-1 I keep the complexity reasonably low, and by keeping 
compiled versions I don't waste cycles doing re-builds of "static" versions.

What I *don't* do, is pick any arbitrary dates when something last 
built.  The reason being I only want to build against something that the 
owners of the dependencies "certified" as being OK.

Note the problem domain here is a bit simpler, as a particular version 
of Xalan-C is only really supposed to work with a particular version of 

Idle thoughts, but maybe useful.


Stefano Mazzocchi wrote:

> Hunsberger, Peter wrote:
>> Stefano Mazzocchi <> writes:
>> <snip/>
>>> I have a RT ready for gump that would allow to solve these issues... 
>>> but I need to work more on this since it appears to be a pretty tough 
>>> computational problem of graph analysis.
>> We do have generalized hedge generator code (both in a Cocoon sense and
>> in a flat query to data structure sense) that I might be able to get you
>> a copy of ;-)...  However, I suspect you need the opposite of what we
>> have; something to break down tree structured data into hedges and look
>> for intersections (cycles)?
> oh, nono, the problem is completely different: when a project doesn't 
> compile, who's fault is that?
> Currently gump has information such as
>  (A) --(depends on)--> (B)
> the problem with this is that if A breaks, it could be because of B's 
> fault or because of A's fault, you can't tell.
> What I'm going to propose is to have bidimensional dependencies:
>  (A,20040302) --(depends on)--> (B,20040212)
> At this point, gump can do multiple builds based on the timestamp and it 
> is possible figure out who broke what and when, in theory point at the 
> very single commit to blame.
> The problem is that the complexity of such trellis grows very big very 
> quickly. I still have to understand if it's duable at all!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message