From: Alex Besogonov (cyberax_at_[hidden])
Date: 2006-09-10 06:04:51
Rene Rivera wrote:
> OK, deciphering that answer... No, and Yes, respectively to the two
> questions I asked ;-) I figured that would be the answer, just wanted to
> make sure that my perceptions matched yours. I guess the C++ port would
> at least help with the type system as it would, hopefully, be easy to
> add those then.
Nope. It would require complete Jam language redesign. I guess I can add
"typed strings" but it won't help much.
> So, I think the best way forward is to make Jam a thin description only
> language plus the build engine and add the ability to embed other more
> useful languages to do anything heavier.
I plan to use Jam language to replace verbose SConstruct scripts.
exe MyExeName : main.c file1.c file2.c ;
looks much better than
Program('MyExeName', ['main.c', 'file1.c', 'file2.c'])
I think it's possible to adapt generators system from BBv2 to SCons
builders system. And SCons is much faster now than it was a year ago.
> Basically what we have now,
> except we get rid of most of the usual "language" constructs like
> looping, branching, etc. and the rules call an embedded language instead
> of Jam.
Looping and branching are not that complex. It's variable expansion and
dependency tracking that I don't like.
> local headers = [ glob-tree [ pwd ] : *.hpp *.ipp *.h *.inc ] ;
> The rule execution would act very much like actions do now, except it
> would be executing the expanded string with the given interpreter.
There are some problems with this approach. First, you need to export
some kind of execution context to the target interpreter. Second, it
won't improve Jam's core features.
-- With respect, Alex Besogonov (cyberax_at_[hidden])
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk