Re: [jamboost] Re: Conditional requirements (from Ali)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-28 06:13:10

David Abrahams wrote:
> Ali has been having trouble posting for some reason; he asked me to
> send this on for him.
>
> ---
>
> Since I last left you all, I've been progressing a bit on extending my
> own make-based build system to Mac OSX and have had to confront this
> conditional requirements issue again in my own context, with some new
> insight resulting.
>
> I have come to believe that the problem here is that BBv2 "properties"
> are used for representing both "configuration aspects" and "tool
> aspects"...inescapably confusing. The former represent aspects that
> the user can request, the latter represent final aspects associated
> with a specific tool, used to generate a command. I agree with
> Volodya that some distinction must be made for properties that can be
> used as conditions, but I don't know that distinguishing simply based
> on attributes such as "free" or "incidental" is the right
> delineation...I think the right distinction is between properties of
> "configuration aspects" and "tool aspects".

In a certain way, the distinction based on attributes is already there. 
Documentation calls non-free non-incidental properties as "base properties", 
which hints that they are in some way more "primary" then the rest. Maybe 
this distinction should be made explicit. I don't know.

[snip]

> Consider:
>
> exe a : a.cpp :
> <variant>debug:<optimization>speed
> <optimization>off:<define>USE_SLOW_BUT_TESTED_ALGORITHM
> ;
>
> In my system, <variant> would be a configuration aspect, but
> <optimization> and <define> would be "tool aspects". Granted, this is
> somewhat of a judgement call...why is <optimization> not part of the
> "configuration"? In my view, because it is too fine-grained a
> property of the "tool" for users to be messing around with. Instead,
> the developer should be able easily to define new "variants" to solve
> this problem.
>
> The developer would introduce (in the Makefile/Jamfile) a new
> "variant" called "debug_slow" resulting in a "requirements" expression
>
> <variant>debug:<optimization>speed
> <variant>debug_slow:<optimization>off,<define>USE_SLOW
>
> The key is making it easy to define new variants.

Wait a minute. You say that in your opinion, optimization is not part of 
configuration, i.e. we should have no <optimization>, but raw CXXFLAGS.
Recasting to cxxflags, we get:

<variant>debug_slow:<cxxflags>???,<define>USE_SLOW

what's to put in cxxflags? How can you express the fact that CXXFLAGS should 
not incude -O3 on gcc? And how will you account for difference in options 
between compilers?

> It's really easy to
> imagine other cases. For example,
>
> on platforms X,Y, and Z use toolset A
> and on toolset A define FOOBAR
>
>
> Looks reasonable, though I'm not sure extra implementation complexity
> is justified.
>
> This is actually a very common case, which is solved in my system by
> layering the various sources of "configuration aspects". In my
> system, there are three abstract types of extensions to the build
> system that are naturally layered ---"os", "tool", and "module-type"
> --- each of which can contribute "configuration aspects".
> (N.B. "module-type" can be thought of as "target-type" in BBv2...in my
> system each Makefile has a single "target-type" associated with
> it...this is not fundamental...conceptually it could support multiple
> target types in a "module" or "project".)
>
> All "os" extensions (e.g. "linux", "cygwin", "darwin", etc) are loaded
> first. Then "module-type" extensions (e.g. "c++lib", "c++exe",
> "distribution", etc) are loaded, each of which pre-loads various tools
> (e.g. "tools/c++", "tools/java", "tools/extract", "tools/patch"
> etc). Thus, concept "module-type" is layered on top of concept "tool",
> which is layered on top of concept "OS".
>
> Thus it is natural that any "configuration aspects" associated with a
> tool can depend upon "configuration aspects" associated with OS. So I
> can express things like
>
> <os>linux:<c++_compiler>gcc,<c++_version>2
> <os>cygwin:<c++_compiler>msvc,<c++_version>7
> <os>darwin:<c++_compiler>gcc,<c++_version>3
>
> <c++_compiler>gcc,<c++_version>3:<define>FOOBAR
>
> but, of course, not the other way around like <compiler>gcc:<os>linux
> (which doesn't make sense anyway...it doesn't make sense because it is
> a quite natural layering to have tools on top of os).

I'm really not sure about this explicit layering. One thing is that I don't 
perceive it as urgent feature in V2. Another thing is that I'm not sure this 
fixed layering is a good thing.

> In summary, I hope that I've expressed some insight into the problem
> by virtue of analyzing an existing working design and how it might
> address the test cases. The two critical design issues for me were to
> separate "configuration aspects" from "tool aspects" and to treat
> "configuration aspects" as layered.
>
> Both the separation and the layering directly reflect the design and
> function of the build system, in which OS extensions are loaded first,
> then Tool extensions; in which "configuration aspects" are computed
> first, then "tool aspects".
>
> I have a lot to say about this from a design standpoint, so I'll just
> stop here and see what you think.

I think we can probably discuss those ideas, but... there's a lot of other 
ideas, which, in my opinion, are more important. For example, we did not 
finally decide if project-target and main-target should be derived from a 
common base or not, to begin with. The property processing proposals are also 
pending. Maybe, we better return to those things?

- Volodya

>
> -Ali