From: John Maddock (boost.regex_at_[hidden])
Date: 2003-08-25 05:38:54
> >and so on. BTW why copy individual files like this, rather than the
> >directory in one go (I think you would need to use "xcopy /S /Y boost
> >wherever" for this on windows to make it work though).
> I could, but copying individual files has several advantages... I can be
> very specific about which files to copy. That one is important because
> happen to be files that are not headers in boost-root/boost :-( I don't
> to write any more cross-platform actions, as the copy works well in all
> platforms we know about.
OK that's fare enough.
> >2) I'm very much against having an automated install - for a lot of users
> >(especially on windows) - it would be sufficient to have the built
> >copied to a central location in the boost tree.
> True for Windows, but not so for *nix where it's expected to have the
> equivalent (sometimes literally) of "make install". Also using the boost
> tree limits how a build/install can be done. Specifically it eliminates
> possibility of building from a read-only source, for example a network
> drive, or cd-rom. And it's not like you can't do it with the current form,
> all you'd have to do is specify "--prefix=.", or as you suggest below
> "--prefix=binaries" ;-)
Not quite that copies headers as well, and I don't want those duplicated
within the boost tree
> >3) I would prefer it if the install/build mechanism was a little more
> >decentralised - if the user just wants to build the regex lib then they
> >should be able to cd into libs/regex/build and invoke bjam from there
> >as they can now.
> I certainly understand the need for decentralised builds for Developers
> Experts. But for Users, those who just downloaded the zip/tar for the
> time, not having a single unified top level build/install is a big hurdle
> from their expectations. Some questions come to mind about the suggestion
> though... Is this more of a Developer maintainance issue? That is are you
> worried about not having control of what gets installed? Or is it more of
> worry about forcing the User to build _everything_? I think these issues
> be solved without having to force the User to "cd libs/*/build ; bjam..".
> First, from the User's point of view, we can support partial builds ala
> autoconf with the "--with-*" and "--without-*" options. ex: --with-regex.
> Second, from the Developer's pov, we can add install support as you
> below, and which I'll elaborate on...
I see too issues:
The user may only want/need to build one or two of the libraries.
The user may be a developer who wants to distribute a subset of boost with
> The even better news is that I already checked in code last night to do
> that :-) Now the three desired options are available: build,
> or build then install. I also added more
options: --builddir, --with-python,
> and --with-pydebug.
Excellent, now I'm almost happy, if we could have the built libraries
gathered together in a common sub-dir in the boost tree as well, then I
really would be happy.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk