gump-general mailing list archives

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

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

Idle thoughts, but maybe useful.

Cheers,
	Berin

Stefano Mazzocchi wrote:

> Hunsberger, Peter wrote:
> 
>> Stefano Mazzocchi <stefano@apache.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message