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
>1) Header copying doesn't work on windows - the path names contain forward
>slashes and that messes up the copy, for example:
>The syntax of the command is incorrect.
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
>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
>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 ;
>doesn't handle the separate install step - the good news is that
>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 -
>installable-lib rule (or whatever it's called) needs to add the
>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,
>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/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
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