Re: [jamboost] Re: Build dirs and in-path features

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
>software.
> 
>
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?
> 
>
Yes.

>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 
./bin/msvc-7.1/debug/link-static/threading-single/user-interface-gui 
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.

Zbynek

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