Re: Why Jam?

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-22 09:48:58

--- 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:
> > > --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > > > --- In boost_at_y..., "braden_mcdaniel" <braden_at_e...> wrote:

> > > 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 disagree.  MSI installations are much friendly then autotools (they 
solve a host of issues not addressed by autotools, including 
registration of components, modifications to the shell and the 
required uninstallation after such changes).  Granted, we have to 
worry about DLL hell, but that's an artifact of the environmnet 
(which is being addressed) not of the tools.  And autotools won't 
help here.

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

Replacing the shell with perl or python would be great for me (for my 
interests outside of work), but still wouldn't allow me to use 
autotools in my work environment. :(

And nearly anything would be better then m4.
 
> > > 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.

I don't disagree.  There was a bit of humor in what I said (see the 
winky?).  However, the consumers of Boost are developers and should 
be able to easily deal with the installation of headers.  Even if 
this means writing a very quick script that can be used by sysops 
that don't have the knowledge required to do this.
 
> > 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.

Tell me what I can do (besides write an autoconf script, which I 
can't do) to help you out here and I'll be very glad to do it.

Bill Kempf