Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-11 14:41:46

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

> > > have exactly opposite opinions.
> >
> > Not exactly: I was proposing to simply use an existing free feature,
> > <define> to achieve that effect. You were the one who suggested that
arity
> > should be a feature at all. Once we do that, I think it should be a
> > non-free non-propagated non-subvariant link-compatible feature.
>
> But... in our discussion we've agreed that neither free properties in
target
> requirements nor free properties in build request can be propagated.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I thought that was in question. As I understood it, you're asking whether
it's OK to prohibit non-propagated free properties from the build request,
and I'm bringing up examples which only work if they're allowed.

> How will <define> setting will take effect?

I don't understand the question. It would take effect in "the usual way"
(i.e. how it works in v1).

> > Still, I can easily imagine a user wanting to "just build this thing
> > with -DFOOBAR=BAZ" (non-propagated). If we take your proposal, it's
> > basically saying that some feature must be specially designed by the
> > Jamfile writer to handle any such configuration.
>
> So, you're saying that free properties in build request should propagated
to
> to *all* targets?

No! What do you mean by "propagated"? I thought "propagated" in this
context meant that requirements of dependencies are automatically imposed
on their dependents.

> I don't like this idea, actually. As for user wanting
> "-DFOOBAR=BAZ" in command line: well, allow that and you can't guaranteed
> correct build anymore. User touches some files and rebuild *some* targets
> with different defines. You can't catch that.

No, you can't.

> I now really feel that free properties in command line is a bad thing.

I understand your concern, but I don't want to overly compromise
ease-of-use in the name of safety. A build system has to work for a
developer who knows what he's doing and "just wants to try it
with -DFOOBAR=BAZ".

> > > Also, not sure that having only a single value per target can be used
to
> > > distinguish targets. Will "warning level" be free feature, for
example?
> >
> > I don't think so.
>
> Because it can have only one value per target?

Yes, and because its values are pre-defined.

> In which case we'd have to
> somehow refine the definition of free property. For me, it's some minor
> aspect of the build process. It affects something but the person running
> build system should be isolated from them. For example, I'd say that
build
> request specifying include paths is rather strange.

In general, that's right. However, you might want to "just try the build
with this other directory shadowing the standard library headers"

> 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.

> > > Hmm.. either you expand that property before calling generate the
first
> > > project target (and your free <define> properties won't be
propagates)
> >
> > Which is what I want in this case.
>
> You want them to be propagated?

No, I want them NOT propagated in this case.

> > I think generator matching and definition is a relatively complicated
> > process. If someone is defining a project which just needs a macro for
> > configuration, I don't want them to have to understand everything about
> > generators in order to support it.
>
> There's yet another approach. We can convert <python-arity> into define
when
> passing properties to the actual generating rule (the one which
constructs
> jam's build action). So, there will be some special handling of features
> prior to construction. Your idea about assining classes to features can
be
> used there.
>
> This is not going to be very heavyweight.

Not sure I understand, but I think that's what I was suggesting.

-Dave