Re: Why Jam?

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-20 17:54:22

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

> 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.
 
> > > 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.
 
> 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 ;).

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.

Bill Kempf