Re: Questions re SCons conversion

From: Ryan Gallagher (ryan.gallagher_at_[hidden])
Date: 2005-10-06 02:01:47

Sorry for the fact that I don't have an answer to any of your questions...

Andreas Fredriksson <deplinenoise <at> gmail.com> writes:
> 
> I've noticed that Boost.Build (and Jam for that matter) doesn't apply
> grist based on paths in the source list in a Jamfile; so if there are
> several subdirectories beneath a subsystem's directory they will all
> be flattened in the object directory; i.e. a/a.cpp b/b.cpp -> a.o b.o.
> Won't this break when there are several files with the same name?
> 

I also would like to know the answer to this. I've been playing a bit with some
different build systems lately, including scons. I started with bbuild v2 and
that ships with Boost 1.33.0 this past weekend. I like the basic structure of
projects and how easy they are to create, and yet are quite powerful. However,
with my test project I quickly ran into this issue. More specifically, I'd like
to write:

project core
: requirements <include>..
<define>CORE_SOURCE
<link>shared:<define>CORE_DYN_LINK
<tag>@$(__name__).tag
: usage-requirements <include>..
;

lib core
: [ glob foo/*.cpp ]
[ glob bar/*.cpp ]
;

But as Andreas points out, the foo and bar namespaces are removed which causes
conflicts in target names when filenames in foo and bar are the same. Other
than creating the targets by hand, which when run does seem slower (msvc)
although I haven't done the proper timing, is there a way to get this to work?

I'd also like to know if the <tag> rule can be moved outside of
$(BOOST_ROOT)/Jamfile.v2 into an importable .jam so that it is more reusable for
others. I like the naming convension (and as you can probably guess,
Boost.Config) and I think it may be useful for others as well.

Also, from playing around a bit I found a couple little issues, but perhaps
these are only because I'm new to bbuild v2 and jam.

1) I wasn't able to get the <include>.. to work without adding the
-I"$(INCLUDE)" options to the command lines in msvc.jam:274,278. Is there
something I'm missing that occurs in the response files?

2) modules.jam:import doesn't import "errors" before using errors.error. Adding
import errors fixes this although perhaps it would need to be checked to make
sure that there isn't the possibility for infinite recursion. Probably
shouldn't be with those branches, but I'm also guessing there's another way to
"import" errors.

I'll appreciate any help with the above, especially help with Andreas' question.

Cheers,

-Ryan