Re: [jamboost] Boost.Build V2, load behaviour part 2.

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
Rene's
> >code.
> >> Besides, it gives more reasonable error messages.
> >
> >Good plan.
>
> I put special effort into those initial error messages, I still
remember the
> initial frustration in figuring out how to setup boost.build ;-) Just
wanted
> 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,
> >largely
> >> because of similarity of this approach to object-oriented
programming.
> >
> >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
> >variables
> >> 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
sense
> >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
is a
> >demonstrated need.
>
> I still see C++ namespace type scoping as the ideal. Myself I set a
good
> number of variables in my project-root. They are not used for
communication,
> they are set to the various locations in my CVS hierarchy so that I
can
> easily refer to them in the Jamfiles. So if it becomes hard to
something
> that is utterly simple now, sepcifically <sysinclude>$(SOMELOCATION),
I
> think we've gone backwards in the translation from V1 to V2.

I understand.

> But then again maybe better use of things like variant and template
will
> reduce my need to do that. Or at least reduce the places where I
directly
> 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
something like
> that but for project variables would solve this quandry. Having a
> "project.global" declaration would allow us to have it both ways.
Having
> such a list would let us automatically make those variables available
to the
> 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
automatically
> 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
from
> >parent
> >> project (and from project root, maybe?)
> >> 2. I believe (and I think we've talked about it some time ago),
that
> >backward
> >> propagation of requirement should be supported. E.g. -- a using
> ><lib>boost in
> >> sources will automatically add boost includes.
> >
> >Agreed.
>
> No. Doing that generically would be a problem for me. If we make that
the
> default behaviour I would need a way to prevent those and other kinds
of
> properties from propagating to other targets. It might not be evident
to
> Boost compiling, after all Boost does the sensible thing of having a
> separate include directory. But I make use of other packages which
aren't
> that sensible. I have to deal with some projects which have different
> settings, and includes for when building the lib, than when using the
lib.

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
mine is
> the location of where we do the loading of
> modules/Jamfiles/porject-roots/etc. I initially modified the
modules.load
> with the goal of keeping the management of loading in one place. But
Dave
> pointed out some drawbacks to changing modules.load, which I agree
with, it
> does make it more convoluted and prone to bugs. But I don't agree on
having
> multiple load routines that all do basically the same thing, that's
even
> 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
for
> this.

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
mentioned.
> If you guys get a chance could you take a look at it. Getting comments
on it
> soon would cool, as opposed to later when it's harder to change :-)

WOW! Tell us where to look!

-Dave