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
> > > such platforms tend not to be so developer-friendly and not as
> > > interested in portability with other platforms. Perhaps the
> > > Jam you speak of offers a ray of hope; but I remain skeptical.
> > Well, Windows isn't really a POSIX platform since it only
> > subset of the POSIX specifications, and I would definately not
> > consider it to be "not so developer-friendly". And I bet the pre-
> > X Mac users would disagree as well. There's others as well, but
> > leave it at this.
> To be fair, it depends on what part of development you look at.
> are certainly some best-of-breed tools under Windows for debugging
> 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
> > > I can see replacing make and automake with Jam; replacing
> > is
> > > a task of a very different magnitude. A lot of folks have tried
> > > replace autoconf with something "better", and no one's really
> > > succeeded. While I can't believe that autoconf is the best
> > > 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
> > 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
> Perl or Python instead of sh. That is probably the initial hurdle,
> 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,
> 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
> > go
> > > a long way toward alleviating issues with making Boost easily
> > deployable.
> > Yes, and no. Currently there's very few Boost libraries that
> > anything more then the headers, which is a very trivial deploy ;).
> Trivial if you're a developer. That's not trivial enough. The
> "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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk