[cmake-developers] Generator expressions for <archive|library|runtime> output directory

[Robert Goulet]

Hi guys, I'm back from my vacation and I plan to look at the issue this week.

I am wondering, could it be a problem of recursion? Because if it was the case, then perhaps it would be better to check for recursion directly in the generator expressions evaluation function and have CMake error out on those, but it's just a wild guess on my part I haven't looked at the code yet.


-----Original Message-----
From: Ben Boeckel [mailto:ben.boeckel at kitware.com] 
Sent: Tuesday, July 21, 2015 11:24 AM
To: Brad King <brad.king at kitware.com>
Cc: Robert Goulet <Robert.Goulet at autodesk.com>; cmake-developers at cmake.org; Stephen Kelly <steveire at gmail.com>
Subject: Re: [cmake-developers] Generator expressions for <archive|library|runtime> output directory

On Tue, Jul 21, 2015 at 10:03:42 -0400, Brad King wrote:
> Okay.  I've made a note about this issue to make sure it is fixed before 3.4.
> 
> Meanwhile I have another comment on genex support in the 
> OUTPUT_DIRECTORY properties.  Currently the properties support both
> 
>  {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY
> 
> and
> 
>  {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY_<CONFIG>
> 
> variants.  When the former is used CMake will still add the /<CONFIG> 
> directory suffix to the end of the value.  When the latter is used 
> CMake does not do this.
> 
> With the former, when a genex like $<CONFIG> is used, it is likely 
> that the user does not want CMake to add the /<CONFIG> suffix.
> Perhaps we should detect when a genex is present in the value and skip 
> adding the suffix, thus trusting the user to have done the right thing 
> (e.g. $<1:value> will still not get a suffix).

+1

The main use case I've come across is when generating modules for languages using CMake. Generally, there you want:

    ${common_output_path}/$<CONFIG>/path/to/module.so

since the interpreter searches using the last path parts from the module import (here, 'path.to.module').

The only way to reliable do it right is to iterate over CMAKE_CONFIGURATION_TYPES and set the properties that way with ${CMAKE_CFGINT_DIR}.

> Of course this would have to be documented carefully.  We could also 
> disallow a genex in the latter (per-config) variants to encourage 
> modern use of the former.

+1

--Ben