cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian package and development of CONS


From: H. S. Teoh
Subject: Re: Debian package and development of CONS
Date: Tue, 26 Aug 2003 10:35:35 -0400
User-agent: Mutt/1.5.4i

On Tue, Aug 26, 2003 at 09:12:02AM -0500, Steven Knight wrote:
> Trying to tie together a few of the threads here...
> 
> > > I recently discovered CONS, but I also discovered it was not maintained
> > > anymore in Debian. The  (the fate? ;-) made that the Debian maintainer
> > > just orphaned CONS with some other packages as I wanted to ask him if he
> > > would mind to...
> > 
> > I'm also a DD, and I was surprised to see cons orphaned. I use Cons a lot,
> > and was in fact considering adopting the package, but didn't because I'm
> > not sure if I have the time to do a good job of it. 
> 
> Taking over maintenance of the Debian package would probably be a lot
> less work than trying to parallelize the current Cons code base.

True. I realized that just after I sent the message. But package
maintenance isn't quite as interesting as coding, so it scratches my itch
more. :-) 

[snip]
> > Personally, I'm up for re-writing Cons to be more amenable to
> > multithreaded builds. If the current Cons maintainers have no more
> > time/interest to work on Cons, I'm considering taking it over. 
> 
> I think there's a way we could get the best of both worlds here.
> 
> >From having worked on it extensively, I can tell you that making Cons
> work with parallel/multithreaded builds will require some MAJOR surgery,
> because its recursive descent of the dependency tree just isn't the
> right architecture for it.  It's proven very difficult to parallelize
> effectively, as you can see if you take a look at the multiple attempts
> that people have already undertaken to retrofit parallelization to Cons.

Yeah, I kinda had the feeling that if I actually undertook the task, I'd
be basically reimplementing the entire thing from scratch. I did glance at
the Cons code once or twice, and I can see why it'd be a pain to retrofit
new features into it.

> However:  CPAN has a Python::Inline module that provides a way to call
> Python code from Perl, and we've designed the SCons build engine from
> the ground-up to be embedded in multiple, alternative interfaces.  Proof
> of concept for this already exists:  Asko Kauppi has written a wrapper
> around the SCons build engine in Lua (an alternate scripting language
> with which I'm otherwise unfamiliar)...

I remember this being mentioned before. I should've looked at SCons
earlier, but I didn't mainly because I know Perl and not Python, and I
wasn't motivated enough to learn Python just to use something that I
already can use Cons for.

> So what I'd like to suggest is that if you are (or anyone else is)
> interested in putting the time into a parallel Cons, that we work
> towards it by wrapping the SCons build engine in a Perl wrapper to
> replicate the Cons interface.  Although it wouldn't be trivial, the more
> extensible architecture and extra capabilities in the SCons build engine
> mean it'll probably be a *lot* more gain for the amount of work put
> in.  For immediate example, a lot of the Cons++ functionality is already
> present in SCons.

I'd say an initial effort ought to be closer to the Python interface than
the existing Cons interface. There are some ugly aspects of the current
Cons interface which I'd rather not spend the time re-creating on the
SCons engine. We can of course revisit it after we have a working Perl
wrapper for SCons, and add compatibility interfaces so that migration to
SCons is easier; but I think any initial effort should be targeted at
making the SCons interface available in Perl rather than reproducing the
current Cons interface. 

> Any takers?  My hope would be that if we can bring the efforts together
> in this way, the whole will be greater than the sum of the parts and
> we'll *all* benefit.
[snip]

I'm interested in helping out in this area. In fact, I think I'll take a
look at SCons right now and familiarize myself with Python.

And about writing the Perl wrapper: what might it involve? Would it need
to have C code to interface Python to Perl, etc.?


T

-- 
Hardware is like a candle, and software like the flame on the candle. Making
many candles actually requires materials and expertise; lighting many flames
needs only one initial flame and is easily done by anyone thereafter.
Hardware manufacturers will always be around; but there aren't many flame
manufacturers around these days.

Attachment: pgp3L0aVoFdzP.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]