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

[Stephen Kelly]

Brad King wrote:

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

I probably can't work on it until next week at the earliest. After porting 
the Windows/XCode generators to handle the type when it gets returned, it 
might be ready (after also fixing the unit test).

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

A rebasing error. I haven't been too careful with that branch as I was 
targetting the following release.

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

I just fixed an unrelated error in the unit test in that branch, and the 
install step in the unit test succeeds, even with that hunk remaining 
(though the test fails later). I have not yet looked into why.


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

Ok, thanks, I'll look into that.

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

Yes.

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

I don't know. Possibly be disallowed.

> What about per-config generation output location?  

Allow generator expressions in the output name, and give the command 
invokation a name without generator expressions:

 file(GENERATE 
   NAME generate_somefile
   OUTPUT_NAME
     somefile$<$<BOOL:$<CONFIGURATION>>:_$<CONFIGURATION>>
   CONTENT
     "Something $<$<CONFIG:Debug>>:totally >cool."
 ) 

 file(GENERATE_APPEND
   NAME generate_somefile
   CONTENT
     ".. which can $<1:also >append."
 )

At configure time, CMakeTmp/generate_somefile.txt is written with the 
generator expressions, and the mapping from generate_somefile to the output 
name is stored in the cache or another file, then it is generated at 
generate time.

My comments in the commit about DEPENDS are not really needed, as this 
happens at generate-time, not build-time. 

> I think this
> should wait until after 2.8.11 was we haven't discussed it much.

Yes, that was my intention too.

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

Yes.

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

Perhaps. 

My intention was to make this an accurate statement:

 CMake target requirements usage is based on linking to targets.

With includes and defines excluded from that, it's not the case as stated at 
the moment. While it is possible to populate the LINK_LIBRARIES property 
with a target to circumvent it, I wouldn't consider that normal use.

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

Yes, something like this:

 macro(target_use_interfaces target scope)
   target_link_libraries(${target} ${scope} ${ARGN})

   set(newscope PUBLIC)

   set(args ${ARGN})

   # ### Shouldn't be LINK_ but it's easier this way.
   if ("${scope}" STREQUAL "LINK_PUBLIC") 
     set(newscope PUBLIC)
   elseif ("${scope}" STREQUAL "LINK_PRIVATE")
     set(newscope PRIVATE)
   elseif ("${scope}" STREQUAL "LINK_INTERFACE_LIBRARIES")
     set(newscope INTERFACE)
   else()
     message(FATAL_ERROR "Scope is required")
   endif()

   set(targets)
   foreach(arg ${args})
     if (TARGET ${arg})
       list(APPEND targets ${arg})
     endif()
   endforeach()

   target_include_directories(${target} ${newscope} ${targets})
   target_compile_definitions(${target} ${newscope} ${targets})
 endmacro()


Instead of passing targets to the new commands it might make more sense to 
pass genex strings. 

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

Ok. Maybe I can do that next week too, though it would probably be a re-hash 
of my 'quirks' email.

Thanks,

Steve.