From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-06 00:34:21
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
> >> 1. Both Rene's initialization code and my project.jam do some
> >crawl-up. Since
> >> crawl-up is needed in initialization anyway, I don't mind using
> >> Besides, it gives more reasonable error messages.
> >Good plan.
> I put special effort into those initial error messages, I still
> initial frustration in figuring out how to setup boost.build ;-) Just
> to make it easier on future users.
Ease of startup is absolutely crucial, so thanks, deep thanks, for
taking the trouble to make sure it would go smoothly for people.
> >> 2. All jamfiles in one module or all jamfiles in separate modules.
> >This is a
> >> big question -- I always thought that module-per-jamfile is better,
> >> because of similarity of this approach to object-oriented
> >When in doubt, I prefer separation of namespaces.
> I also prefer Jamfiles being in separate spaces.
Wonderful, we're all in agreement!
> >> In
> >> fact, there more than one variable that describe a project and so
> >making each
> >> Jamfile a module seems reasonable, while the only drawback is using
> >> defined in project root.
> >I hope that users won't do much communication via variables. However,
> >see Steve K's posting on variable exporting. I think it might make
> >to have something similar. I favor a style of exporting which makes
> >variables visible in everything lower down in the (sub)project
> >hierarchy. Finally, I think we shouldn't implement this until there
> >demonstrated need.
> I still see C++ namespace type scoping as the ideal. Myself I set a
> number of variables in my project-root. They are not used for
> they are set to the various locations in my CVS hierarchy so that I
> easily refer to them in the Jamfiles. So if it becomes hard to
> that is utterly simple now, sepcifically <sysinclude>$(SOMELOCATION),
> think we've gone backwards in the translation from V1 to V2.
> But then again maybe better use of things like variant and template
> reduce my need to do that. Or at least reduce the places where I
> use variables.
> Hmmm, now that I keep thinking about I'm reminded about one of the
> constructs we have which we barely use, "path-global". Having
> that but for project variables would solve this quandry. Having a
> "project.global" declaration would allow us to have it both ways.
> such a list would let us automatically make those variables available
> Jamfile modules.
> OK, so here is my suggestion:
> 1. Do individual modules per Jamfile.
> 2. Do individual modules per project-root file.
> 3. Have a "project-global" declaration whose variables are
> made available in the Jamfile modules.
We can easily automatically export the bindings, but of course we cannot
easily make them look like variables. In other words, we can make this
work with the proviso that the user doesn't try to modify the variable
in a subproject.
> >> Frankly, I never realized we have this problem. But:
> >> 1. It probably not very important. First, we'll inherit includes
> >> project (and from project root, maybe?)
> >> 2. I believe (and I think we've talked about it some time ago),
> >> propagation of requirement should be supported. E.g. -- a using
> ><lib>boost in
> >> sources will automatically add boost includes.
> No. Doing that generically would be a problem for me. If we make that
> default behaviour I would need a way to prevent those and other kinds
> properties from propagating to other targets. It might not be evident
> Boost compiling, after all Boost does the sensible thing of having a
> separate include directory. But I make use of other packages which
> that sensible. I have to deal with some projects which have different
> settings, and includes for when building the lib, than when using the
I understand your problem with this approach, but I always assumed that
there would be a way to distinguish the internal from exported #include
directories. It's very common to have a directory of headers used just
for building a lib, and another for the lib's external interface.
It will probably be important to give people a way to disable the
automatic inheritance of #include paths completely, or on a per-library
basis. One reason might be that users will want fine-grained control
over the order of the search.
> Another discrepancy I'd like to bring up between Valdimir's code and
> the location of where we do the loading of
> modules/Jamfiles/porject-roots/etc. I initially modified the
> with the goal of keeping the management of loading in one place. But
> pointed out some drawbacks to changing modules.load, which I agree
> does make it more convoluted and prone to bugs. But I don't agree on
> multiple load routines that all do basically the same thing, that's
> more prone to bugs.
Agreed, unless one load routine calls the other. There's nothing at all
wrong with re-using the name "load". I confess to not having analyzed
Vladimir's "load" code at all. Can someone summarize what it's doing
that's different from modules.load?
> So that boils it down to needing another module that
> does the file load management. Would a "file" module be apporpriate
It depends whether we need it.
> And is there more functionality other than load that can become part
> of that? (one I can think of right now is "file.glob").
I suggest not worrying about things like that. We are still relatively
nimble. If we find we have a module with one rule and there's a better
place for that rule, we'll just move it.
> PS. Last Sunday I put a preliminary version of the doc system I
> If you guys get a chance could you take a look at it. Getting comments
> soon would cool, as opposed to later when it's harder to change :-)
WOW! Tell us where to look!
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