Re: Why Jam?

From: braden_mcdaniel (braden_at_[hidden])
Date: 2002-02-22 12:41:49

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

It is not appropriate to compare MSI to the autotools. Apples and
oranges. The autotools are build tools; MSI is a means for
distributing and deploying binaries. It would be more accurate to
compare RPM to MSI.

RPM addresses "DLL hell" with inter-package dependency tracking. It is
not as end-user-friendly as MSI, but it probably does a better job of
ensuring the integrity of the system. I must admit, though, that I
don't know a whole lot about MSI.

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

So what approach to the problem autoconf addresses *would* work in
your environment?

> And nearly anything would be better then m4.

"Nearly anything" won't necessarily accomplish what m4 accomplishes.
What would be some viable alternatives?

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

The "our consumers are developers" excuse is frequently produced as
grounds for shirking the issues of deployment. It doesn't wash; it's
not even true. Your consumers are the persons who need to use the
software you produce. Period. Ultimately, *somebody* has to deal with
deployment issues. You can pass the buck to other developers, but
don't have any illusions about doing so. When the buck is passed like
this, it means a bunch of people downstream have to solve the same
problem individually because it wasn't solved at the source. The
upshot is that the barrier to using your software is raised.

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

Installation must be as simple as "./configure;make;make install". It
doesn't have to be those commands exactly, but that spirit of
simplicity must be intact. If Boost can get there with Jam, that's
fine by me.

Braden