Re: Why Jam?

From: braden_mcdaniel (braden_at_[hidden])
Date: 2002-02-21 18:59:08

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., "braden_mcdaniel" <braden_at_e...> wrote:
> > --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > > --- In boost_at_y..., "braden_mcdaniel" <braden_at_e...> wrote:
> > > > Maybe later, but not now. I'm not really using Boost yet, 
> though I
> > > > anticipate doing so in the future. A requirement for me is that 
> my
> > > > users are able to obtain dependencies for my package easily, and
> > > > install those dependencies without having to do things like set
> > > > environment variables, install obscure build tools, or do 
> anything
> > > > else out of the ordinary. A person compiling my package may not 
> be 
> > > an
> > > > experienced software developer.
> > > 
> > > automake+autoconf fails some of your criteria unless the platform 
> is 
> > > restricted to POSIX platforms.  On the other hand, work is being 
> done 
> > > to make all of the above true for Jam.
> > 
> > I have little hope of my criteria being met on non-POSIX platforms;
> > such platforms tend not to be so developer-friendly and not as
> > interested in portability with other platforms. Perhaps the work on
> > Jam you speak of offers a ray of hope; but I remain skeptical.
> 
> Well, Windows isn't really a POSIX platform since it only contains a 
> subset of the POSIX specifications, and I would definately not 
> consider it to be "not so developer-friendly".  And I bet the pre-OS 
> X Mac users would disagree as well.  There's others as well, but I'll 
> leave it at this.

To be fair, it depends on what part of development you look at. There
are certainly some best-of-breed tools under Windows for debugging and
performance metrics. But where deployment is concerned, Windows is
downright developer-*hostile*.

> > I can see replacing make and automake with Jam; replacing autoconf 
> is
> > a task of a very different magnitude. A lot of folks have tried to
> > replace autoconf with something "better", and no one's really
> > succeeded. While I can't believe that autoconf is the best possible
> > tool for its role, it does suck less than the alternatives.
> 
> Actually, autoconf is a fairly simple concept.  I would expect it 
> would be possible to "invent" an alternative that's not as tied to 
> POSIX.

The most obvious (and probably the most significant) dependency on
POSIX in autoconf is the requirement of sh to run the configuration
script. It would be possible (and indeed it has been proposed) to use
Perl or Python instead of sh. That is probably the initial hurdle, and
it is probably also the one that is conceptually the easiest to
overcome--even though it is a lot of work to implement. Thornier
issues arrive after that: is m4 an acceptable dependency? If not, what
should it be replaced with?

> > > > So when the time comes, I'll have to see where Boost is and 
> evaluate
> > > > my options:
> > > > 
> > > >  * Add an install target to the Jam build system.
> > > 
> > > This one is already being discussed and worked on.
> > 
> > On this list or elsewhere? (I don't remember seeing such a 
> discussion
> > here, but I could have missed it. I'm not able to read every message
> > to this list.)
> 
> It's been discussed here in the past.  It's also been discussed on 
> the jamboost group.

Thanks. I'll have to look over the archives.

First I have to do some catching up on this thread. It looks like
danl_miller has some very interesting suggestions. If it's decided
that an autotools build is an acceptable (even if incomplete) solution
to the deployment problem, I would be glad to help out.

> > In any event, that's very good to hear. A sane install target would 
> go
> > a long way toward alleviating issues with making Boost easily 
> deployable.
> 
> Yes, and no.  Currently there's very few Boost libraries that require 
> anything more then the headers, which is a very trivial deploy ;).

Trivial if you're a developer. That's not trivial enough. The command
"jam install" (or similar) needs to put the headers in a place that
client apps (or the compiler itself) can find them automatically.

> We are starting to outgrow this, though, which is why there's an 
> effort to add this to Boost.Build.  I feel the pain more then most, 
> since I maintain one of the few libraries that actually requires 
> compilation of libraries.

Boost.Thread is acutally what I'm primarily interested in using.

Braden