Re: Hmmm.... future of cons?

> > Exactly. I have moved several of my personal projects to Cons. Why do I
> > have to revisit all of them again just to re-write the conscripts for
> > SCons?
>
> Indeed, why would you have to?

Ok - to answer a (probably) rhetorical question - because old code never dies -
but it often needs to be maintained...
So in two years when some genius comes out with C#++ or whatever, some of the
new code will be written in it - and it will need support for a new dependancy
scanner, etc...   If that support ends up in scons and not cons, and developers
here start to use it - I'll have to switch to scons...

If cons is truely going to be retired - I will probably have no choice but to
rewrite all my cons files in scons/python at some point in the reasonably near
future - since the sooner I do it the less painful it will be...

What I'd *really*, *really* like to see is something a few people have mentioned
idly before - a interpreter independant core, with a variety of front ends...
If things are put together right it shouldn't matter whether you use perl or
python or whatever as your front-end...  And at that stage, I don't really even
*care* what language the backend is written in...

I'm afraid I've only used python a bit - does anyone know if it would be
possible to access python objects from perl?

I'd be quite happy to see 2.3.1 or 2.4 be a 'retirement' version of cons as it
stands today, and have cons 3.0 be a thin perl wrapper around scons...

I certainly don't want to see wasted effort, and it sounds like refactoring cons
would definitely duplicate a lot of the effort than went into scons...   On the
other hand, I'd rather not have to rewrite the perl code in my current
Cons{truct,cript} files in python to get at any new functionality, either...

Warren





_______________________________________________
[email protected]
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/