Re: [jamboost] Re: Common install [was; Common Lib Subdir]

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
whole
> >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
there
> happen to be files that are not headers in boost-root/boost :-( I don't
need
> to write any more cross-platform actions, as the copy works well in all
the
> 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
> libraries
> >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
the
> 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
just
> >as they can now.
>
> I certainly understand the need for decentralised builds for Developers
and
> Experts. But for Users, those who just downloaded the zip/tar for the
first
> 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
a
> worry about forcing the User to build _everything_? I think these issues
can
> 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
mention
> 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
their project.

> The even better news is that I already checked in code last night to do
just
> that :-) Now the three desired options are available: build,
build+install,
> 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.

John.