Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 07:22:02

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> David Abrahams wrote:
>
> > > > > BTW, this is exactly what V1 does. See the attached example.
> > > >
> > > > Yes, I know that. It's no accident: I designed it that way.
> > >
> > > Sorry, but I don't understand why is it so. If I say
> > > <cxxflags>-funsigned-char in command line, I'd expect that to apply
to
> > > every compilation.
>
> No comment on this?

No. You're allowed to have your expectation. Maybe we should accomodate it.

> > > > level feature since I wrote it. In fact, I think I've changed my
mind
> >
> > about
> >
> > > > what the meaning of "free" should be.
> > >
> > > And what's the new meaning, in your opinion. I can't gather that from
> >
> > your
> >
> > > previous posts.
> >
> > Merely that its values can be arbitrary strings, instead of being known
to
> > the system via the feature's declaration or feature.extend.
>
> Well, that's okay, but we'd need orthogonal principal feature -> minor
> feature axis as well. Do you mean that free property can be also
multivalued,
> or that's another axis?

Did you miss the post where I wrote:

<<
you wrote:
> I think we can just add a kind of free property which can have only one
> value. This is an alternative to non-free features without subvariant
dir,
> and I think it's better. Let's keep ordinary features simple: they
> significally affect build and generate subvariant dir.

Then let's just scrap the notion of "free" properties and introduce two
orthogonal attributes as a replacement:

multi-valued
no-subvariant

Maybe there is still a place for a "free" attribute which means that the
feature's values can be arbitrary text (like <define> and <include>).
Warning levels would not be free, since we'll want to pick some useful
pre-defined values.
>>

??

or does that fail to address the issue?

> > I'm not sure I agree with that. AFAIK you have to edit a Jamfile to
change
> > those.
>
> Yes, that's what I mean. Edit requirements of the top-level project in
> Jamfile. I'm trying to say that building with different defines is the
same
> as changing *requirements* in Jamfile.
>
> > Furthermore, if I have a project with 5 libraries and an executable,
and I
> > want to try building libA with -DFOOBAR=BAZ and link it into the rest
of
> > the project as usual, it seems very difficult or impossible to achieve
that
> > by working with top-level project requirements.
>
> Why, no. You
> 1) Change top-level requirements as you like
> 2) You build only libA
> 3) You change your requirements back.
> 4) You build everything else.
>
> I agree that actually changing Jamfile would be troublesome and command
line
> interface would be better. But I feel that project-wide requirements,
which
> apply to all target is the right way here, because build request would
apply
> only to top-level targets.

Sometimes that's what you want.
Well, anyway, I'd prefer something more-explicit.

Let me give you another use-case, for example. I just added a switch called
BOOST_PYTHON_TRACE_REGISTRY to Boost.Python, which prints out a bunch of
diagnostic info for testing purposes. If I want to use it, all I have to do
is:

bjam "-sBUILD=<define>BOOST_PYTHON_TRACE_REGISTRY" -a registry.obj

It has the advantage of being entirely temporary. I don't have to edit the
Jamfile, and there's no risk that I'll check in the Jamfile with this
option mistakenly enabled for everyone.

There *must* be an easy way to do things like this.

> > > Possibly, we can allow to specify additional top-level
> > > requirements in the command line? That way, they'll be consistently
> >
> > applied
> >
> > > to all targets. I realize that this is rather confusing,
> >
> > VERY confusing. And I don't see how it provides any of the protection
you
> > say you want, since it's still a command-line interface to essentially
the
> > same functionality.
>
> It has no protection at all. I'm now trying to find some way to specify
> global free properties and build request doesn't appears the right place.

>From a user's POV, having one place to specify builds on the command-line
is much better than having two. If you want to filter some things out of
the build request and move them to requirements internally, to satisfy your
own sense of purity, be my guest.

> > I think we need to keep searching.
>
> Definitely. Personally, I'll get some pizza and hope my brain will be
working
> better in 15 minutes ;-)

How is the pizza in Moscow?