[cmake-developers] What's still cooking in my clone

[Brad King]

On 01/16/2013 12:36 PM, Stephen Kelly wrote:
>  * INTERFACE_LIBRARY-target-type
> 
> Adding an INTERFACE_LIBRARY type to cmake. This is needed for things like 
> header-only libraries. Needs to touch other generators to handle the new 
> type.

I think this one should go in 2.8.11.

What is this hunk:

 +  if (this->TargetTypeValue == INTERFACE_LIBRARY)
 +    {
 +//     this->PolicyStatusCMP0119 = cmPolicies::NEW;
 +    }

?

Shouldn't this hunk be removed later in the topic:

+    case cmTarget::INTERFACE_LIBRARY:
       this->Target->GetMakefile()->IssueMessage(cmake::INTERNAL_ERROR,
         "cmInstallTargetGenerator created with non-installable target.");

when install is allowed?

>  * compatible-interface-strings
> 
> This one is similar to the COMPATIBLE_INTERFACE_BOOL, but we don't have any 
> concrete need for it yet. Other than that, it's ready to merge I think.

Yes, but older compilers e.g. VS6 will not properly handle function
templates where the template type does not appear in the argument list.
You can work around it by adding a "T*=0" argument at the end.  Also
this will need test cases.

>  * install-interface-includes
> 
> Convenience for setting the includes install interface of installed targets. 
> Needs some more design in case there are other 'install artifacts' which 
> might usefully be related to INTERFACE properties on install (what others 
> are there?).

As discussed in the previous thread on this one I'd like to wait to
gain some experience with the new features on which this builds.
That will be after 2.8.11.

>  * join-genex
> 
> Adding a JOIN generator expression, and requiring a way to generate files at 
> generate time with generator expression content. This is for more-
> declarative and target-orientated macro use. Needs API design.

Interesting idea.  What should file(GENERATE) do in script mode?
What about per-config generation output location?  I think this
should wait until after 2.8.11 was we haven't discussed it much.

>  * tll-includes-defines
> 
> I realized that as no one is using the INTERFACE_INCLUDE_DIRECTORIES yet, 
> there is no need for a policy on this one. Of course, that option expires 
> with the release of 2.8.11. I'll drop that branch then if it is not merged.

This goes back to the "great debate".  While no policy is needed,
Alex's concern is still valid.  Having target_link_libraries do
linking, includes, and definitions while target_include_directories
and target_compile_definitions do only what their name says will
be inconsistent, confusing, and surprising to users.

Can the behavior of target_use_interfaces now be done with a macro
that just does tll, tid, and tcd internally?  I'm not saying this
should be the solution, just wondering if it is now that simple.

I think you should start a new dedicated thread for this one that
summarizes the current state of master and what you propose.

Thanks,
-Brad