Re: Common install [was; Common Lib Subdir]

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-08-23 12:26:31

[2003-08-23] John Maddock wrote:

>OK, here's my take on what Rene has so far:
>
>First off, well done - you've got a lot further with this than I managed to
>do!
>
>1) Header copying doesn't work on windows - the path names contain forward
>slashes and that messes up the copy, for example:
>
>FileClone
C:\Boost\include\boost-131\boost\compatibility\cpp_c_headers\ctime
>The syntax of the command is incorrect.
>
> copy
>c:\data\boost\develop\boost/boost/compatibility/cpp_c_headers\ctime
>C:\Boost\include\boost-131\boost\compatibility\cpp_c_headers\ctime
>
>....failed FileClone
>C:\Boost\include\boost-131\boost\compatibility\cpp_c_headers\ctime...

OK, I'll fix that. Beman repoerted that it wasn't working but not the reason
:-) The strange thing is, it works just fine for me in Win2K.

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

>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" ;-)

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

>Before I got stuck with the way the stage rule works, I was messing about
>with something like this:
>
>rule installable-lib ( target : sources + : requirements * : default-build
>* )
>{
> lib $(target) : $(sources) : $(requirements) : $(default-build) ;
> return [ stage $(TOP)/install/lib : <lib>$(target) :
>boost-install-stage-tag : debug release ] ;
>}
>
>which doesn't actually work properly, but I think you can see where I'm
>going with this, now library authors just change lib to installable-lib and
>dll to installable-dll, and everything should "just work". 

Yes I see where you're going ;-) My idea, and a simpler way for Developers,
was to add an "install" rule as such:

rule install ( name type : sources * : options * )

Ex, for regex you would add:

install regex lib : <lib>boost_regex <dll>boost_regex ;

This has the advantage the you can also add:

install regex doc : ../*.txt ../doc/*.html ;

>However this
>doesn't handle the separate install step - the good news is that
testing.jam
>has something very similar: the "run" rule builds the .exe if you just
>invoke bjam, and then if you do a "bjam test" it does the second step and
>runs the tests as well. This is basically how we want install to work -
the
>installable-lib rule (or whatever it's called) needs to add the
installation
>stage to the target called "install". 

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.

>Unfortunately, I've never been able
>to figure out how testing.jam actually does that - part of the problem is
>that I just don't "get" the jam language at all, sorry, I've even read the
>manual as well :-)

Manual doesn't help much ;-] Putting a bunch of ECHOs and seeing what goes
on is a much better learning experience for Jam.

>4) where should the local copy go? Most open source libraries use
>project-root/lib, but we already have a "libs" directory which is a little
>too similar IMO, so how about boost-root/binaries/lib and
>boost-root/binaries/bin, or is that too convoluted?

Doesn't seem that convoluted... others...

boost-root/bins/..
boost-root/install/..
boost-root/build/.. (happens to be an existing CVS directory already)

>5) Mangled names - I think these needs careful consideration - 

Yes. And given that this email is getting long... I'll split here and
respond to that on another thread.

>Thanks for persevering with this,

Slowly but surely ;-)

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq