Re: Some thoughts on targets

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-08 08:39:11

Vladimir Prus <ghost_at_[hidden]> writes:

> Use case 1. Suppose my program_options library is accepted to Boost,
> and I'm pressed to implement both library version and all-inline version.
> Someone might want to write
>
> exe hello : hello.cpp @/boost/program_options%program_options ;
>
> Ordinary, a library target will be created, and usage requirements (like 
> <include>/path/to/boost) will be applied. When user wants all-inline version
> (using some feature, for example), he'd get no real target to consume, but 
> still, the usage requirements must be applied. 

Those sound to me like two different subvariants of the same main
target. Just as you can ask for the library with inlining off you
might also request the library completely in headers. Is that
pushing the notion of "library target" too far?

Also, I may have missed something, but is there a reason we need two
tweaky symbols to specify remote main targets? Can't a syntax like
/boost/program_options_at_program_options do that job?

> Related case: I would like to use some headers-only library from
> Boost. I should be able to write:
>
> exe hello : hello.cpp : <use>@/boost ;
>
> Here, @/boost is a project, and most likely you don't want to get all 
> libraries built. You, however, do want to get usage requirements. 
>
> I think in both cases some "not-file" virtual-target much be created, which 
> will carry usage requirement, but will not be consumed.
>
> Use case 2.
>
> exe hello : hello.cpp platform_sources ;
> alias platform_sources : win.cpp : <os>NT ;
> alias platform_sources ;
>
> Now, on any OS except for NT, the "platform_sources" main target will generate 
> no files. I think this should be allowed.

Sure.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com