From: Zbynek Winkler (zw-bjam_at_[hidden])
Date: 2004-12-11 06:51:12
David Abrahams wrote:
>Zbynek Winkler wrote:
>>While reading some previous posts related to build dirs I thought I chip in.
>>I think scons is more intuitive regarding this issue. By default it
>>builds to the same dir
>The same dir as what?
Sorry for not being explicit enough. My fault. Same dir as source.
>>*but* it also computes hash of all commands used
>>to build a certain file. If the user desires a different build dir can
>>be specified (a variant can be created).
>What does the hash have to do with this?
>I think i actually know the answer, but it's only because I understand
>how Scons works -- what you've written above seems pretty disconnected.
It means that if you switch compilers, add/remove flags etc. the files
that should be rebuilt are rebuilt. For boost build this is true only to
certain extent - only if you add feature that is represented in the
build path. More on this at the end....
>Building into the current directory has some major disadvantages for
>Boost developers who are trying to write multiplatform, multi-compiler
Sorry for not being clear on this either. I do not propose to build to
the current directory all the time. I just think that it is very very
nice to have the *option* to build to directories specific to
variant/compiler but it would be IMHO better not to be forced to it.
Sometimes I make a little program that is meant to test a certain thing,
I play with it, keep it around a while and eventually delete it. GNU
make has a nice feature that it can build an executable from a single
source file without Makefile (having file foo.c and issuing 'make foo'
builds the exe) which is great for such work.
Boost Build until recently required to create two files
(project-root.jam and Jamfile), one empty and one with 'exe foo : foo.c
;' in it. When building it forces on me the multiplatform/multicompiler
stuff on me with no way to disable it. Do not get me wrong - the
multiplatform/multicompiler stuff is great for bigger longer lasting
projects but not really needed for a little tools and experiments.
>>This has several nice properties. The most important (at least for me)
>>is that if you change the SConscript (Jamfile) the relevant files are
>>rebuilt. This very thing hits me again and again.
>We've had plans for a long time to make targets dependent on the
>Jamfiles that specify them. That wouldn't preserve Scons' nice property
>that you can edit the SConscript in benign ways (like adding comments)
>without causing a rebuild.
Even that would be an useful improvement.
>>Combined with the fact
>>that "--clean" or "-a" options behave strange (clean too much/deep), it
>>is very hard to use.
>I suppose you're talking about Boost.Build now instead of Scons?
>I think you'd better be more explicit, particularly about what you mean
>by too much/deep.
I wanted to find the issue number in the bug database but I could not
find it (the bug database). I've checked
http://boost.org/boost-build2/doc/html/index.html and the pages with the
new logo because I remember it (the bug tracker) lives zigzag.cs.msu.su
but I had no luck. Finally I've found
http://boost.org/tools/build/v2/doc/tracker.html and the address
http://zigzag.cs.msu.su:7814/ but that returns "HTTP Status 500". If you
point me to a working bug tracker I'll find you the issue about
'cleaning too much/deep'.
>>Also the build hierarchy of scons is more intuitive
>>and the built files can be more easily found. [if only scons had
>>user-requirements I'd really consider switching...]
>>What is your view of this? Do you think that the complicated build dir
>>structure has some important properties that I do not see? Is it
>>superior in some way?
>It allows you to easily keep builds with different variants, compilers,
>and options separate so that you can pursue a compile/edit/debug cycle
>without rebuilding the world each time you're interested in looking at
>something new. It's very common for me to fire off a single bjam
>command that tests a library against ten or eleven different compilers.
Ok, fair enough. But it would be nice if boost build considered also
people without eleven different compilers ;-). Why do I have to look for
my executable in directory
even when it is the *only* variant I ever want to build? Actually, at
the beginning I do not know that *this* exactly is the variant I want.
First I try to build the project but it does not work so I keep adding
and adding options which results in a wild hierarchy of directories with
partially built files that I don't want :(. If the tool I am building
uses some library also built by BB I cannot use the '-a' option to
rebuild the tool (I'd want to do that when I add some free property not
represented in the path) because that also rebuild all the libraries
(the issue about cleaning to deep). So I have to go and manually delete
the offending parts :(.
I was trying to suggest something that would improve the experience
above. By default the build dir would be equal to the source dir and
hashes would be used to determine if update is necessary. The developers
with eleven different compilers would be able to say (somehow) that
there should be separate directories for each of them. I think this is
the way scons works (I have not used it that much). It allows interested
parties to create variant builds but it does not force them on you.
PS. I was trying to be as explicit as possible but some parts still
might not be clear enough. I that case just ask and I'll try to do my
best explaining myself.
-- http://zw.matfyz.cz/ http://robotika.cz/ Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic
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