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,
> > > anticipate doing so in the future. A requirement for me is that
> > > 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
> > > else out of the ordinary. A person compiling my package may not
> > an
> > > experienced software developer.
> > automake+autoconf fails some of your criteria unless the platform
> > restricted to POSIX platforms. On the other hand, work is being
> > 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
> 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
> > > So when the time comes, I'll have to see where Boost is and
> > > 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
> 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
> a long way toward alleviating issues with making Boost easily
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk