Re: [jamboost] Disallow free property in build request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-12 07:19:14

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?

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

> > > > 2) You say propagated feature apply to top-level targets. Do you mean
> > >
> > > that
> > >
> > > > bjam warnings=full
> > > >
> > > > will cause only top-level targets compiled with full warnings, while
>
> main
>
> > > > targets they depend on will use standard warning option?!
> > >
> > > Uh, no -- that would sort of defeat any meaning to the "propagated"
> > > attribute, wouldn't it?
> >
> > Sure, so this part of comment should be updated also.
>
> Okay. When we decide the meanings for all of these feature attributes, I'll
> make a pass through and update the comments and code.

Okay.

> > I think you agree that you can accomplish that goal with requirements on
>
> the
>
> > top-level project.
>
> 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.

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

> > but other alternatives are even more confusing for me.
>
> 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 ;-)

- Volodya