Re: [CMake] Generator expressions containing spaces

[Elvis Stansvik]

2018-04-24 21:37 GMT+02:00 Yves Frederix :
> There is no real need to go through an intermediate variable. The following
> should work:
>
> add_compile_options(
>"$<$:-Wall;-Wextra;-Werror>"
> )

Ah, of course. Thanks.

Elvis

>
> Yves
>
>
> On Tue, Apr 24, 2018 at 6:58 PM, Elvis Stansvik
>  wrote:
>>
>> 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc :
>> > The space is used to separate arguments passed to COMMAND. So your
>> > generator
>> > expression is splitted before evaluation and elements are no longer
>> > valid
>> > generator expression.
>> >
>> >
>> >
>> > So, to solve your problem, encapsulate the generator expression inside
>> > quotes. And apply the following advices for correct result:
>> >
>> > Separate command from args
>> > Use variable to list your arguments and add option COMMAND_EXPAND_LISTS
>> > (available with version 3.8) to avoid “spurious” semi-colons in the
>> > result
>> >
>> >
>> >
>> > Your example reworked:
>> >
>> >
>> >
>> > Set (args foo bar)
>> >
>> > add_custom_target(foo)
>> >
>> > add_custom_command(TARGET foo POST_BUILD
>> >
>> >   COMMAND $<1:echo> "$<1 :${args}>"
>> >
>> >   COMMAND_EXPAND_LISTS
>> >
>> >   )
>> >
>>
>> Interesting thread. I was sort of in the same boat, having a
>>
>> add_compile_options(
>> "$<$:-Wall>"
>> "$<$:-Wextra>"
>> "$<$:-Werror>"
>>
>> "$<$:-Wall>"
>> "$<$:-Wextra>"
>> "$<$:-Werror>"
>>
>> "$<$:-Wall>"
>> "$<$:-Wextra>"
>> "$<$:-Werror>"
>> )
>>
>> and of course wishing I could just write something like
>>
>> add_compile_options(
>> $<$:-Wall -Wextra -Werror>
>> $<$:-Wall -Wextra -Werror>
>> $<$:-Wall -Wextra -Werror>
>> )
>>
>> instead.
>>
>> I can't depend on CMake 3.8+ just yet, but I'll remember your solution
>> for when I can.
>>
>> I don't quite like having to introduce variables though. Is there no
>> way to solve this without having to first stuff the elements in a list
>> and use that?
>>
>> Cheers,
>> Elvis
>>
>> >
>> >
>> >
>> >
>> > From: CMake  on behalf of Yves Frederix
>> > 
>> > Date: Monday 23 April 2018 at 13:08
>> > To: "cmake@cmake.org" 
>> > Subject: [CMake] Generator expressions containing spaces
>> >
>> >
>> >
>> > Hi,
>> >
>> >
>> >
>> > I recently learned that the COMMAND line in a custom command supports
>> > generator expressions. In particular, what makes this powerful is that
>> > if
>> > the expression evaluates to the empty string, no corresponding code will
>> > be
>> > added to the target (as documented in the docs).
>> >
>> >
>> >
>> > While this works very nicely for single-string command, I fail to make
>> > it
>> > work for commands consisting of multiple space-separated strings:
>> >
>> >
>> >
>> > ```
>> >
>> > ~/tmp/genex_with_spaces$ cat CMakeLists.txt
>> > cmake_minimum_required(VERSION 3.6)
>> >
>> >
>> >
>> > add_custom_target(foo)
>> >
>> > add_custom_command(TARGET foo POST_BUILD
>> >
>> >   COMMAND $<1:echo bar>
>> >
>> >   )
>> >
>> >
>> >
>> > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
>> > "\$$<1:echo" bar>
>> >
>> > ```
>> >
>> >
>> >
>> > As can be seen, the generator expression is not expanded.
>> >
>> >
>> >
>> > My question is now whether I am doing something wrong (is there a
>> > correct
>> > way of dealing with spaces in the context of generator expressions?) or
>> > might this be an inherent limitation of generator expression in general?
>> >
>> >
>> >
>> > As a workaround, the only thing that seems to work is to put each of the
>> > space-separated components of the command in (typically identical)
>> > genexes:
>> >
>> >
>> >
>> > ```
>> >
>> > ~/tmp/genex_with_spaces$ cat CMakeLists.txt
>> > cmake_minimum_required(VERSION 3.6)
>> >
>> >
>> >
>> > add_custom_target(foo)
>> >
>> > add_custom_command(TARGET foo POST_BUILD
>> >
>> >   COMMAND $<1:echo> $<1:bar>
>> >
>> >   )
>> >
>> >
>> >
>> > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
>> > echo bar
>> >
>> > ```
>> >
>> >
>> > Of course, while this works, things becomes very unreadable if the genex
>> > is
>> > more complex.
>> >
>> >
>> >
>> > Other things that I have tried but failed:
>> >
>> > escape the space with a backslash -> this quotes the entire expression
>> > inside the genex.
>> > define the command directly as a list inside the genex -> this removes
>> > spaces between the different components of the command and quotes that
>> > result.
>> > treat the command as a list, perform string operations to wrap each
>> > element
>> > in the desired regex and convert semicolon to spaces -> again results in
>> > the
>> > command being quoted as a whole.
>> >
>> >
>> >
>> > Any advice is highly appreciated.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Yves
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> > http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Kitware offers various services to support the CMake communi

Re: [CMake] Generator expressions containing spaces

[Yves Frederix]

There is no real need to go through an intermediate variable. The following
should work:

add_compile_options(
   "$<$:-Wall;-Wextra;-Werror>"
)

Yves


On Tue, Apr 24, 2018 at 6:58 PM, Elvis Stansvik <
elvis.stans...@orexplore.com> wrote:

> 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc :
> > The space is used to separate arguments passed to COMMAND. So your
> generator
> > expression is splitted before evaluation and elements are no longer valid
> > generator expression.
> >
> >
> >
> > So, to solve your problem, encapsulate the generator expression inside
> > quotes. And apply the following advices for correct result:
> >
> > Separate command from args
> > Use variable to list your arguments and add option COMMAND_EXPAND_LISTS
> > (available with version 3.8) to avoid “spurious” semi-colons in the
> result
> >
> >
> >
> > Your example reworked:
> >
> >
> >
> > Set (args foo bar)
> >
> > add_custom_target(foo)
> >
> > add_custom_command(TARGET foo POST_BUILD
> >
> >   COMMAND $<1:echo> "$<1 :${args}>"
> >
> >   COMMAND_EXPAND_LISTS
> >
> >   )
> >
>
> Interesting thread. I was sort of in the same boat, having a
>
> add_compile_options(
> "$<$:-Wall>"
> "$<$:-Wextra>"
> "$<$:-Werror>"
>
> "$<$:-Wall>"
> "$<$:-Wextra>"
> "$<$:-Werror>"
>
> "$<$:-Wall>"
> "$<$:-Wextra>"
> "$<$:-Werror>"
> )
>
> and of course wishing I could just write something like
>
> add_compile_options(
> $<$:-Wall -Wextra -Werror>
> $<$:-Wall -Wextra -Werror>
> $<$:-Wall -Wextra -Werror>
> )
>
> instead.
>
> I can't depend on CMake 3.8+ just yet, but I'll remember your solution
> for when I can.
>
> I don't quite like having to introduce variables though. Is there no
> way to solve this without having to first stuff the elements in a list
> and use that?
>
> Cheers,
> Elvis
>
> >
> >
> >
> >
> > From: CMake  on behalf of Yves Frederix
> > 
> > Date: Monday 23 April 2018 at 13:08
> > To: "cmake@cmake.org" 
> > Subject: [CMake] Generator expressions containing spaces
> >
> >
> >
> > Hi,
> >
> >
> >
> > I recently learned that the COMMAND line in a custom command supports
> > generator expressions. In particular, what makes this powerful is that if
> > the expression evaluates to the empty string, no corresponding code will
> be
> > added to the target (as documented in the docs).
> >
> >
> >
> > While this works very nicely for single-string command, I fail to make it
> > work for commands consisting of multiple space-separated strings:
> >
> >
> >
> > ```
> >
> > ~/tmp/genex_with_spaces$ cat CMakeLists.txt
> > cmake_minimum_required(VERSION 3.6)
> >
> >
> >
> > add_custom_target(foo)
> >
> > add_custom_command(TARGET foo POST_BUILD
> >
> >   COMMAND $<1:echo bar>
> >
> >   )
> >
> >
> >
> > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
> > "\$$<1:echo" bar>
> >
> > ```
> >
> >
> >
> > As can be seen, the generator expression is not expanded.
> >
> >
> >
> > My question is now whether I am doing something wrong (is there a correct
> > way of dealing with spaces in the context of generator expressions?) or
> > might this be an inherent limitation of generator expression in general?
> >
> >
> >
> > As a workaround, the only thing that seems to work is to put each of the
> > space-separated components of the command in (typically identical)
> genexes:
> >
> >
> >
> > ```
> >
> > ~/tmp/genex_with_spaces$ cat CMakeLists.txt
> > cmake_minimum_required(VERSION 3.6)
> >
> >
> >
> > add_custom_target(foo)
> >
> > add_custom_command(TARGET foo POST_BUILD
> >
> >   COMMAND $<1:echo> $<1:bar>
> >
> >   )
> >
> >
> >
> > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
> > echo bar
> >
> > ```
> >
> >
> > Of course, while this works, things becomes very unreadable if the genex
> is
> > more complex.
> >
> >
> >
> > Other things that I have tried but failed:
> >
> > escape the space with a backslash -> this quotes the entire expression
> > inside the genex.
> > define the command directly as a list inside the genex -> this removes
> > spaces between the different components of the command and quotes that
> > result.
> > treat the command as a list, perform string operations to wrap each
> element
> > in the desired regex and convert semicolon to spaces -> again results in
> the
> > command being quoted as a whole.
> >
> >
> >
> > Any advice is highly appreciated.
> >
> >
> >
> > Thanks,
> >
> > Yves
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects a

Re: [CMake] Generator expressions containing spaces

[Elvis Stansvik]

2018-04-24 18:58 GMT+02:00 Elvis Stansvik :
> 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc :
>> The space is used to separate arguments passed to COMMAND. So your generator
>> expression is splitted before evaluation and elements are no longer valid
>> generator expression.
>>
>>
>>
>> So, to solve your problem, encapsulate the generator expression inside
>> quotes. And apply the following advices for correct result:
>>
>> Separate command from args
>> Use variable to list your arguments and add option COMMAND_EXPAND_LISTS
>> (available with version 3.8) to avoid “spurious” semi-colons in the result
>>
>>
>>
>> Your example reworked:
>>
>>
>>
>> Set (args foo bar)
>>
>> add_custom_target(foo)
>>
>> add_custom_command(TARGET foo POST_BUILD
>>
>>   COMMAND $<1:echo> "$<1 :${args}>"
>>
>>   COMMAND_EXPAND_LISTS
>>
>>   )
>>
>
> Interesting thread. I was sort of in the same boat, having a
>
> add_compile_options(
> "$<$:-Wall>"
> "$<$:-Wextra>"
> "$<$:-Werror>"
>
> "$<$:-Wall>"
> "$<$:-Wextra>"
> "$<$:-Werror>"
>
> "$<$:-Wall>"
> "$<$:-Wextra>"
> "$<$:-Werror>"
> )

Sidenote: I know that in this case, since I want the same flags for
all three of these compilers, I could "simplify" it using an
$, but that's a separate thing (and I decided against it
since it gives such long unreadable lines).

Elvis

>
> and of course wishing I could just write something like
>
> add_compile_options(
> $<$:-Wall -Wextra -Werror>
> $<$:-Wall -Wextra -Werror>
> $<$:-Wall -Wextra -Werror>
> )
>
> instead.
>
> I can't depend on CMake 3.8+ just yet, but I'll remember your solution
> for when I can.
>
> I don't quite like having to introduce variables though. Is there no
> way to solve this without having to first stuff the elements in a list
> and use that?
>
> Cheers,
> Elvis
>
>>
>>
>>
>>
>> From: CMake  on behalf of Yves Frederix
>> 
>> Date: Monday 23 April 2018 at 13:08
>> To: "cmake@cmake.org" 
>> Subject: [CMake] Generator expressions containing spaces
>>
>>
>>
>> Hi,
>>
>>
>>
>> I recently learned that the COMMAND line in a custom command supports
>> generator expressions. In particular, what makes this powerful is that if
>> the expression evaluates to the empty string, no corresponding code will be
>> added to the target (as documented in the docs).
>>
>>
>>
>> While this works very nicely for single-string command, I fail to make it
>> work for commands consisting of multiple space-separated strings:
>>
>>
>>
>> ```
>>
>> ~/tmp/genex_with_spaces$ cat CMakeLists.txt
>> cmake_minimum_required(VERSION 3.6)
>>
>>
>>
>> add_custom_target(foo)
>>
>> add_custom_command(TARGET foo POST_BUILD
>>
>>   COMMAND $<1:echo bar>
>>
>>   )
>>
>>
>>
>> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
>> "\$$<1:echo" bar>
>>
>> ```
>>
>>
>>
>> As can be seen, the generator expression is not expanded.
>>
>>
>>
>> My question is now whether I am doing something wrong (is there a correct
>> way of dealing with spaces in the context of generator expressions?) or
>> might this be an inherent limitation of generator expression in general?
>>
>>
>>
>> As a workaround, the only thing that seems to work is to put each of the
>> space-separated components of the command in (typically identical) genexes:
>>
>>
>>
>> ```
>>
>> ~/tmp/genex_with_spaces$ cat CMakeLists.txt
>> cmake_minimum_required(VERSION 3.6)
>>
>>
>>
>> add_custom_target(foo)
>>
>> add_custom_command(TARGET foo POST_BUILD
>>
>>   COMMAND $<1:echo> $<1:bar>
>>
>>   )
>>
>>
>>
>> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
>> echo bar
>>
>> ```
>>
>>
>> Of course, while this works, things becomes very unreadable if the genex is
>> more complex.
>>
>>
>>
>> Other things that I have tried but failed:
>>
>> escape the space with a backslash -> this quotes the entire expression
>> inside the genex.
>> define the command directly as a list inside the genex -> this removes
>> spaces between the different components of the command and quotes that
>> result.
>> treat the command as a list, perform string operations to wrap each element
>> in the desired regex and convert semicolon to spaces -> again results in the
>> command being quoted as a whole.
>>
>>
>>
>> Any advice is highly appreciated.
>>
>>
>>
>> Thanks,
>>
>> Yves
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cma

Re: [CMake] Generator expressions containing spaces

[Elvis Stansvik]

2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc :
> The space is used to separate arguments passed to COMMAND. So your generator
> expression is splitted before evaluation and elements are no longer valid
> generator expression.
>
>
>
> So, to solve your problem, encapsulate the generator expression inside
> quotes. And apply the following advices for correct result:
>
> Separate command from args
> Use variable to list your arguments and add option COMMAND_EXPAND_LISTS
> (available with version 3.8) to avoid “spurious” semi-colons in the result
>
>
>
> Your example reworked:
>
>
>
> Set (args foo bar)
>
> add_custom_target(foo)
>
> add_custom_command(TARGET foo POST_BUILD
>
>   COMMAND $<1:echo> "$<1 :${args}>"
>
>   COMMAND_EXPAND_LISTS
>
>   )
>

Interesting thread. I was sort of in the same boat, having a

add_compile_options(
"$<$:-Wall>"
"$<$:-Wextra>"
"$<$:-Werror>"

"$<$:-Wall>"
"$<$:-Wextra>"
"$<$:-Werror>"

"$<$:-Wall>"
"$<$:-Wextra>"
"$<$:-Werror>"
)

and of course wishing I could just write something like

add_compile_options(
$<$:-Wall -Wextra -Werror>
$<$:-Wall -Wextra -Werror>
$<$:-Wall -Wextra -Werror>
)

instead.

I can't depend on CMake 3.8+ just yet, but I'll remember your solution
for when I can.

I don't quite like having to introduce variables though. Is there no
way to solve this without having to first stuff the elements in a list
and use that?

Cheers,
Elvis

>
>
>
>
> From: CMake  on behalf of Yves Frederix
> 
> Date: Monday 23 April 2018 at 13:08
> To: "cmake@cmake.org" 
> Subject: [CMake] Generator expressions containing spaces
>
>
>
> Hi,
>
>
>
> I recently learned that the COMMAND line in a custom command supports
> generator expressions. In particular, what makes this powerful is that if
> the expression evaluates to the empty string, no corresponding code will be
> added to the target (as documented in the docs).
>
>
>
> While this works very nicely for single-string command, I fail to make it
> work for commands consisting of multiple space-separated strings:
>
>
>
> ```
>
> ~/tmp/genex_with_spaces$ cat CMakeLists.txt
> cmake_minimum_required(VERSION 3.6)
>
>
>
> add_custom_target(foo)
>
> add_custom_command(TARGET foo POST_BUILD
>
>   COMMAND $<1:echo bar>
>
>   )
>
>
>
> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
> "\$$<1:echo" bar>
>
> ```
>
>
>
> As can be seen, the generator expression is not expanded.
>
>
>
> My question is now whether I am doing something wrong (is there a correct
> way of dealing with spaces in the context of generator expressions?) or
> might this be an inherent limitation of generator expression in general?
>
>
>
> As a workaround, the only thing that seems to work is to put each of the
> space-separated components of the command in (typically identical) genexes:
>
>
>
> ```
>
> ~/tmp/genex_with_spaces$ cat CMakeLists.txt
> cmake_minimum_required(VERSION 3.6)
>
>
>
> add_custom_target(foo)
>
> add_custom_command(TARGET foo POST_BUILD
>
>   COMMAND $<1:echo> $<1:bar>
>
>   )
>
>
>
> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
> echo bar
>
> ```
>
>
> Of course, while this works, things becomes very unreadable if the genex is
> more complex.
>
>
>
> Other things that I have tried but failed:
>
> escape the space with a backslash -> this quotes the entire expression
> inside the genex.
> define the command directly as a list inside the genex -> this removes
> spaces between the different components of the command and quotes that
> result.
> treat the command as a list, perform string operations to wrap each element
> in the desired regex and convert semicolon to spaces -> again results in the
> command being quoted as a whole.
>
>
>
> Any advice is highly appreciated.
>
>
>
> Thanks,
>
> Yves
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensour

Re: [CMake] Generator expressions containing spaces

[Yves Frederix]

It seems COMMAND_EXPAND_LISTS was indeed the key here. Thanks a lot!

Yves

On Mon, Apr 23, 2018 at 2:11 PM, CHEVRIER, Marc 
wrote:

> The space is used to separate arguments passed to COMMAND. So your
> generator expression is splitted before evaluation and elements are no
> longer valid generator expression.
>
>
>
> So, to solve your problem, encapsulate the generator expression inside
> quotes. And apply the following advices for correct result:
>
>- Separate command from args
>- Use variable to list your arguments and add option
>COMMAND_EXPAND_LISTS (available with version 3.8) to avoid “spurious”
>semi-colons in the result
>
>
>
> Your example reworked:
>
>
>
> Set (args foo bar)
>
> add_custom_target(foo)
>
> add_custom_command(TARGET foo POST_BUILD
>
>   COMMAND $<1:echo> "$<1 :${args}>"
>
>   COMMAND_EXPAND_LISTS
>
>   )
>
>
>
>
>
> *From: *CMake  on behalf of Yves Frederix <
> yves.frederix+cm...@gmail.com>
> *Date: *Monday 23 April 2018 at 13:08
> *To: *"cmake@cmake.org" 
> *Subject: *[CMake] Generator expressions containing spaces
>
>
>
> Hi,
>
>
>
> I recently learned that the COMMAND line in a custom command supports
> generator expressions. In particular, what makes this powerful is that if
> the expression evaluates to the empty string, no corresponding code will be
> added to the target (as documented in the docs
> 
> ).
>
>
>
> While this works very nicely for single-string command, I fail to make it
> work for commands consisting of multiple space-separated strings:
>
>
>
> ```
>
> ~/tmp/genex_with_spaces$ cat CMakeLists.txt
>
> cmake_minimum_required(VERSION 3.6)
>
>
>
> add_custom_target(foo)
>
> add_custom_command(TARGET foo POST_BUILD
>
>   COMMAND $<1:echo bar>
>
>   )
>
>
>
> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
> "\$$<1:echo" bar>
>
> ```
>
>
>
> As can be seen, the generator expression is not expanded.
>
>
>
> My question is now whether I am doing something wrong (is there a correct
> way of dealing with spaces in the context of generator expressions?) or
> might this be an inherent limitation of generator expression in general?
>
>
>
> As a workaround, the only thing that seems to work is to put each of the
> space-separated components of the command in (typically identical) genexes:
>
>
>
> ```
>
> ~/tmp/genex_with_spaces$ cat CMakeLists.txt
>
> cmake_minimum_required(VERSION 3.6)
>
>
>
> add_custom_target(foo)
>
> add_custom_command(TARGET foo POST_BUILD
>
>   COMMAND $<1:echo> $<1:bar>
>
>   )
>
>
>
> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make
> echo bar
>
> ```
>
>
> Of course, while this works, things becomes very unreadable if the genex
> is more complex.
>
>
>
> Other things that I have tried but failed:
>
>- escape the space with a backslash -> this quotes the entire
>expression inside the genex.
>- define the command directly as a list inside the genex -> this
>removes spaces between the different components of the command and quotes
>that result.
>- treat the command as a list, perform string operations to wrap each
>element in the desired regex and convert semicolon to spaces -> again
>results in the command being quoted as a whole.
>
>
>
> Any advice is highly appreciated.
>
>
>
> Thanks,
>
> Yves
>
>
>
>
>
>
>
>
>
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions containing spaces

[CHEVRIER, Marc]

The space is used to separate arguments passed to COMMAND. So your generator 
expression is splitted before evaluation and elements are no longer valid 
generator expression.

So, to solve your problem, encapsulate the generator expression inside quotes. 
And apply the following advices for correct result:

  *   Separate command from args
  *   Use variable to list your arguments and add option COMMAND_EXPAND_LISTS 
(available with version 3.8) to avoid “spurious” semi-colons in the result

Your example reworked:

Set (args foo bar)
add_custom_target(foo)
add_custom_command(TARGET foo POST_BUILD
  COMMAND $<1:echo> "$<1 :${args}>"
  COMMAND_EXPAND_LISTS
  )


From: CMake  on behalf of Yves Frederix 

Date: Monday 23 April 2018 at 13:08
To: "cmake@cmake.org" 
Subject: [CMake] Generator expressions containing spaces

Hi,

I recently learned that the COMMAND line in a custom command supports generator 
expressions. In particular, what makes this powerful is that if the expression 
evaluates to the empty string, no corresponding code will be added to the 
target (as documented in the 
docs).

While this works very nicely for single-string command, I fail to make it work 
for commands consisting of multiple space-separated strings:

```
~/tmp/genex_with_spaces$ cat CMakeLists.txt 
 cmake_minimum_required(VERSION 
3.6)

add_custom_target(foo)
add_custom_command(TARGET foo POST_BUILD
  COMMAND $<1:echo bar>
  )

~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make   
 "\$$<1:echo" bar>
```

As can be seen, the generator expression is not expanded.

My question is now whether I am doing something wrong (is there a correct way 
of dealing with spaces in the context of generator expressions?) or might this 
be an inherent limitation of generator expression in general?

As a workaround, the only thing that seems to work is to put each of the 
space-separated components of the command in (typically identical) genexes:

```
~/tmp/genex_with_spaces$ cat CMakeLists.txt 
 cmake_minimum_required(VERSION 
3.6)

add_custom_target(foo)
add_custom_command(TARGET foo POST_BUILD
  COMMAND $<1:echo> $<1:bar>
  )

~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make   
 echo bar
```

Of course, while this works, things becomes very unreadable if the genex is 
more complex.

Other things that I have tried but failed:

  *   escape the space with a backslash -> this quotes the entire expression 
inside the genex.
  *   define the command directly as a list inside the genex -> this removes 
spaces between the different components of the command and quotes that result.
  *   treat the command as a list, perform string operations to wrap each 
element in the desired regex and convert semicolon to spaces -> again results 
in the command being quoted as a whole.

Any advice is highly appreciated.

Thanks,
Yves





-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator Expressions and FetchContent

[Saad Khattak]

I do use target_link_libraries when it comes to C++ projects and it works
wonderfully for them. However, in this case, my base project has a bunch of
helper files with CMake functionality that help me work with and build my
library of projects (which you can see here
https://github.com/2LoC/tl_base_ci).

Of course, these helper .cmake files (with the functionality I want) are in
the tl_base_ci project which can be either (1) cloned separately, built,
(2) Installed without building, or (3) cloned through ExternalProject_Add
(which I am trying to convert to FetchContent). In all cases, the include
directories might differ, which is why I use rely on the generator
expressions expanding.

In projects depending on tl_base_ci (e.g.
https://github.com/2LoC/tl_proj_template), I have CMake includes like this:

include("${tl_base_ci_INCLUDE_DIRECTORY}/tl_base_ci/tl_common.cmake") # in
the actual project, it's slightly different as it searches for the file in
a list of directories returned by
get_target_property(... INTERFACE_INCLUDE_DIRECTORIES)

Where the tl_base_ci_INCLUDE_DIRECTORY might differ. So ultimately I was
hoping for a way to reliably include the helper .cmake files (i.e. figure
out tl_base_ci's include directory path). I did that with
get_target_property(...) which worked great for ExternalProject_Add, but
did not work so well for FetchContent because the generator expressions did
not expand.

Hopefully I was able to explain the problem well. If there is any
confusion, please let me know.



On Mon, Mar 19, 2018 at 7:11 AM Craig Scott  wrote:

> On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak 
> wrote:
>
>> Thank you for the clarification Craig.
>>
>> >> If you made your main target link against LibA, you'd see that CMake
>> automatically expands out the generator expressions when it constructs the
>> link command line for main, so the example as it stands doesn't actually
>> have any error.
>>
>> In my actual project, a library like LibA has .cmake files that can be
>> included by dependent projects to reuse. Of course, CMake `include` does
>> not get affected by target_link_libraries.
>>
>> I would like dependent projects to have the ability to use an existing
>> clone of LibA, if found (e.g. using find_package), otherwise clone locally
>> for using ExternalProject_Add which I am now trying to refactor to
>> FetchContent. Another option open to dependent projects is to force the
>> FetchContent on all repositories regardless of what find_package returns
>> (this is great for testing locally to ensure I have no uncommitted,
>> unpushed changes).
>>
>> Using existing clones is a way to ensure that every project dependent on
>> LibA doesn't clone it's own copy (unless forced to do so).
>>
>> To allow the possibility for any dependent project to include the .cmake
>> files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
>> (using get_target_property) for LibA and then include the .cmake utility
>> files like this:
>>
>> include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)
>>
>> Perhaps I am approaching the problem incorrectly? Essentially, I would
>> like a way to reliably include .cmake files found in LibA's include folder
>> regardless of how LibA was acquired (e.g. cloned and built and/or installed
>> separately or acquired using FetchContent). In my case, I could only think
>> of the above as a reliable way to include the files.
>>
>
> Rather than focusing on including files, I would choose to base things
> around targets. If the rest of your project simply links against the
> required target name, the target itself should bring with it any transitive
> dependencies such as required header search paths, dependent libraries that
> must also be linked, etc. These are the INTERFACE_... properties that can
> be set on a target, usually by commands such as
> target_include_directories(foo INTERFACE ...), target_link_libraries(foo
> INTERFACE ...), etc. When building directly from your source tree, the
> targets will be directly available. When using find_package(), the package
> should provide import targets. The rest of your project shouldn't really
> need to care which one of the two it is dealing with. This is the
> recommended way to structure a situation like this. You shouldn't need to
> also pull in a secondary .cmake file in most circumstances, but maybe I'm
> missing something about your particular situation.
>
>
>
>>
>> On Sun, Mar 18, 2018 at 4:22 PM Craig Scott 
>> wrote:
>>
>>> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak 
>>> wrote:
>>>
 Absolutely. Please find the example project here:
 https://github.com/samaursa/cmake_fetch_content_and_generator_expressions


 The repository README also includes the output from running
 `./setup.sh`.

>>>
>>>
>>> Okay that's much clearer, thanks. The example is doing what I'd expect
>>> and the generator expressions are also expected to be visible at the point
>>> your example is printing them. If you made your m

Re: [CMake] Generator Expressions and FetchContent

[Craig Scott]

On Mon, Mar 19, 2018 at 8:25 AM, Saad Khattak  wrote:

> Thank you for the clarification Craig.
>
> >> If you made your main target link against LibA, you'd see that CMake
> automatically expands out the generator expressions when it constructs the
> link command line for main, so the example as it stands doesn't actually
> have any error.
>
> In my actual project, a library like LibA has .cmake files that can be
> included by dependent projects to reuse. Of course, CMake `include` does
> not get affected by target_link_libraries.
>
> I would like dependent projects to have the ability to use an existing
> clone of LibA, if found (e.g. using find_package), otherwise clone locally
> for using ExternalProject_Add which I am now trying to refactor to
> FetchContent. Another option open to dependent projects is to force the
> FetchContent on all repositories regardless of what find_package returns
> (this is great for testing locally to ensure I have no uncommitted,
> unpushed changes).
>
> Using existing clones is a way to ensure that every project dependent on
> LibA doesn't clone it's own copy (unless forced to do so).
>
> To allow the possibility for any dependent project to include the .cmake
> files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
> (using get_target_property) for LibA and then include the .cmake utility
> files like this:
>
> include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)
>
> Perhaps I am approaching the problem incorrectly? Essentially, I would
> like a way to reliably include .cmake files found in LibA's include folder
> regardless of how LibA was acquired (e.g. cloned and built and/or installed
> separately or acquired using FetchContent). In my case, I could only think
> of the above as a reliable way to include the files.
>

Rather than focusing on including files, I would choose to base things
around targets. If the rest of your project simply links against the
required target name, the target itself should bring with it any transitive
dependencies such as required header search paths, dependent libraries that
must also be linked, etc. These are the INTERFACE_... properties that can
be set on a target, usually by commands such as
target_include_directories(foo INTERFACE ...), target_link_libraries(foo
INTERFACE ...), etc. When building directly from your source tree, the
targets will be directly available. When using find_package(), the package
should provide import targets. The rest of your project shouldn't really
need to care which one of the two it is dealing with. This is the
recommended way to structure a situation like this. You shouldn't need to
also pull in a secondary .cmake file in most circumstances, but maybe I'm
missing something about your particular situation.



>
> On Sun, Mar 18, 2018 at 4:22 PM Craig Scott 
> wrote:
>
>> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak 
>> wrote:
>>
>>> Absolutely. Please find the example project here: https://github.com/
>>> samaursa/cmake_fetch_content_and_generator_expressions
>>>
>>> The repository README also includes the output from running
>>> `./setup.sh`.
>>>
>>
>>
>> Okay that's much clearer, thanks. The example is doing what I'd expect
>> and the generator expressions are also expected to be visible at the point
>> your example is printing them. If you made your main target link against
>> LibA, you'd see that CMake automatically expands out the generator
>> expressions when it constructs the link command line for main, so the
>> example as it stands doesn't actually have any error.
>>
>> Generator expressions are not expanded when CMake is processing the files
>> (called the *configure* stage), they are expanded only when writing out
>> the Makefiles during the *generation* stage. When running cmake from the
>> command line, one doesn't tend to think of these two phases as being
>> distinct, but you can see it at the end of the cmake log with these two
>> messages:
>>
>> -- Configuring done
>> -- Generating done
>>
>> It is clearer when using the CMake GUI application because you get two
>> different buttons, one for Configure and another for Generate, so you have
>> to trigger both phases manually. So if you look at the contents of various
>> properties and variables with CMake commands like message(...), you are
>> doing that during the configure stage and therefore will see unexpanded
>> generator expressions.
>>
>>
>>
>>
>>>
>>> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott 
>>> wrote:
>>>
 Can you provide a small project example that can be used to demonstrate
 your problem? The specifics of how you are doing things may be important.


 On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak 
 wrote:

> Hi,
>
> ExternalProject_Add builds, generates and installs and thus any
> generator expressions used will be expanded by the time another library
> uses it.
>
> For example, if I add a library LibA using ExternalProject_Add, I can
> then query th

Re: [CMake] Generator Expressions and FetchContent

[Saad Khattak]

Thank you for the clarification Craig.

>> If you made your main target link against LibA, you'd see that CMake
automatically expands out the generator expressions when it constructs the
link command line for main, so the example as it stands doesn't actually
have any error.

In my actual project, a library like LibA has .cmake files that can be
included by dependent projects to reuse. Of course, CMake `include` does
not get affected by target_link_libraries.

I would like dependent projects to have the ability to use an existing
clone of LibA, if found (e.g. using find_package), otherwise clone locally
for using ExternalProject_Add which I am now trying to refactor to
FetchContent. Another option open to dependent projects is to force the
FetchContent on all repositories regardless of what find_package returns
(this is great for testing locally to ensure I have no uncommitted,
unpushed changes).

Using existing clones is a way to ensure that every project dependent on
LibA doesn't clone it's own copy (unless forced to do so).

To allow the possibility for any dependent project to include the .cmake
files properly, I get the INTERFACE_INCLUDE_DIRECTORIES target property
(using get_target_property) for LibA and then include the .cmake utility
files like this:

include(${LibA_INCLUDE_DIRECTORY}/my_utility.cmake)

Perhaps I am approaching the problem incorrectly? Essentially, I would like
a way to reliably include .cmake files found in LibA's include folder
regardless of how LibA was acquired (e.g. cloned and built and/or installed
separately or acquired using FetchContent). In my case, I could only think
of the above as a reliable way to include the files.



On Sun, Mar 18, 2018 at 4:22 PM Craig Scott  wrote:

> On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak 
> wrote:
>
>> Absolutely. Please find the example project here:
>> https://github.com/samaursa/cmake_fetch_content_and_generator_expressions
>>
>>
>> The repository README also includes the output from running `./setup.sh`.
>>
>
>
> Okay that's much clearer, thanks. The example is doing what I'd expect and
> the generator expressions are also expected to be visible at the point your
> example is printing them. If you made your main target link against LibA,
> you'd see that CMake automatically expands out the generator expressions
> when it constructs the link command line for main, so the example as it
> stands doesn't actually have any error.
>
> Generator expressions are not expanded when CMake is processing the files
> (called the *configure* stage), they are expanded only when writing out
> the Makefiles during the *generation* stage. When running cmake from the
> command line, one doesn't tend to think of these two phases as being
> distinct, but you can see it at the end of the cmake log with these two
> messages:
>
> -- Configuring done
> -- Generating done
>
> It is clearer when using the CMake GUI application because you get two
> different buttons, one for Configure and another for Generate, so you have
> to trigger both phases manually. So if you look at the contents of various
> properties and variables with CMake commands like message(...), you are
> doing that during the configure stage and therefore will see unexpanded
> generator expressions.
>
>
>
>
>>
>> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott 
>> wrote:
>>
>>> Can you provide a small project example that can be used to demonstrate
>>> your problem? The specifics of how you are doing things may be important.
>>>
>>>
>>> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak 
>>> wrote:
>>>
 Hi,

 ExternalProject_Add builds, generates and installs and thus any
 generator expressions used will be expanded by the time another library
 uses it.

 For example, if I add a library LibA using ExternalProject_Add, I can
 then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the
 include directory for the library:

 get_target_property(LibA_INCLUDE_DIRECTORIES LibA
   INTERFACE_INCLUDE_DIRECTORIES
   )

 This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
 CMake include(...) statements. However, with FetchContent, this is no
 longer possible.

 The reason I would like to query a variable is because at project
 generation time, I invoke FetchContent only if LibA is not found by
 find_package(LibA).

 Thus, the include directory for LibA may be in the current build
 directory (through FetchContent) OR it may be found in the folder where
 LibA is cloned by the user and generated/built OR an INSTALL of LibA.

 Perhaps I should not be using `get_target_property` to get the a
 library's include directory? Either way, would like some guidance in
 solving this issue.

 Thank you,
 Saad


 --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
>

Re: [CMake] Generator Expressions and FetchContent

[Craig Scott]

On Mon, Mar 19, 2018 at 3:44 AM, Saad Khattak  wrote:

> Absolutely. Please find the example project here: https://github.com/
> samaursa/cmake_fetch_content_and_generator_expressions
>
> The repository README also includes the output from running `./setup.sh`.
>


Okay that's much clearer, thanks. The example is doing what I'd expect and
the generator expressions are also expected to be visible at the point your
example is printing them. If you made your main target link against LibA,
you'd see that CMake automatically expands out the generator expressions
when it constructs the link command line for main, so the example as it
stands doesn't actually have any error.

Generator expressions are not expanded when CMake is processing the files
(called the *configure* stage), they are expanded only when writing out the
Makefiles during the *generation* stage. When running cmake from the
command line, one doesn't tend to think of these two phases as being
distinct, but you can see it at the end of the cmake log with these two
messages:

-- Configuring done
-- Generating done

It is clearer when using the CMake GUI application because you get two
different buttons, one for Configure and another for Generate, so you have
to trigger both phases manually. So if you look at the contents of various
properties and variables with CMake commands like message(...), you are
doing that during the configure stage and therefore will see unexpanded
generator expressions.




>
> On Sat, Mar 17, 2018 at 6:47 PM Craig Scott 
> wrote:
>
>> Can you provide a small project example that can be used to demonstrate
>> your problem? The specifics of how you are doing things may be important.
>>
>>
>> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak 
>> wrote:
>>
>>> Hi,
>>>
>>> ExternalProject_Add builds, generates and installs and thus any
>>> generator expressions used will be expanded by the time another library
>>> uses it.
>>>
>>> For example, if I add a library LibA using ExternalProject_Add, I can
>>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the
>>> include directory for the library:
>>>
>>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA
>>>   INTERFACE_INCLUDE_DIRECTORIES
>>>   )
>>>
>>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
>>> CMake include(...) statements. However, with FetchContent, this is no
>>> longer possible.
>>>
>>> The reason I would like to query a variable is because at project
>>> generation time, I invoke FetchContent only if LibA is not found by
>>> find_package(LibA).
>>>
>>> Thus, the include directory for LibA may be in the current build
>>> directory (through FetchContent) OR it may be found in the folder where
>>> LibA is cloned by the user and generated/built OR an INSTALL of LibA.
>>>
>>> Perhaps I should not be using `get_target_property` to get the a
>>> library's include directory? Either way, would like some guidance in
>>> solving this issue.
>>>
>>> Thank you,
>>> Saad
>>>
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/
>>> opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator Expressions and FetchContent

[Saad Khattak]

Absolutely. Please find the example project here:
https://github.com/samaursa/cmake_fetch_content_and_generator_expressions

The repository README also includes the output from running `./setup.sh`.

On Sat, Mar 17, 2018 at 6:47 PM Craig Scott  wrote:

> Can you provide a small project example that can be used to demonstrate
> your problem? The specifics of how you are doing things may be important.
>
>
> On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak 
> wrote:
>
>> Hi,
>>
>> ExternalProject_Add builds, generates and installs and thus any generator
>> expressions used will be expanded by the time another library uses it.
>>
>> For example, if I add a library LibA using ExternalProject_Add, I can
>> then query the target property INTERFACE_INCLUDE_DIRECTORIES and get the
>> include directory for the library:
>>
>> get_target_property(LibA_INCLUDE_DIRECTORIES LibA
>>   INTERFACE_INCLUDE_DIRECTORIES
>>   )
>>
>> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
>> CMake include(...) statements. However, with FetchContent, this is no
>> longer possible.
>>
>> The reason I would like to query a variable is because at project
>> generation time, I invoke FetchContent only if LibA is not found by
>> find_package(LibA).
>>
>> Thus, the include directory for LibA may be in the current build
>> directory (through FetchContent) OR it may be found in the folder where
>> LibA is cloned by the user and generated/built OR an INSTALL of LibA.
>>
>> Perhaps I should not be using `get_target_property` to get the a
>> library's include directory? Either way, would like some guidance in
>> solving this issue.
>>
>> Thank you,
>> Saad
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator Expressions and FetchContent

[Craig Scott]

Can you provide a small project example that can be used to demonstrate
your problem? The specifics of how you are doing things may be important.


On Sun, Mar 18, 2018 at 8:12 AM, Saad Khattak  wrote:

> Hi,
>
> ExternalProject_Add builds, generates and installs and thus any generator
> expressions used will be expanded by the time another library uses it.
>
> For example, if I add a library LibA using ExternalProject_Add, I can then
> query the target property INTERFACE_INCLUDE_DIRECTORIES and get the include
> directory for the library:
>
> get_target_property(LibA_INCLUDE_DIRECTORIES LibA
>   INTERFACE_INCLUDE_DIRECTORIES
>   )
>
> This allows me to then use the variable LibA_INCLUDE_DIRECTORIES in my
> CMake include(...) statements. However, with FetchContent, this is no
> longer possible.
>
> The reason I would like to query a variable is because at project
> generation time, I invoke FetchContent only if LibA is not found by
> find_package(LibA).
>
> Thus, the include directory for LibA may be in the current build directory
> (through FetchContent) OR it may be found in the folder where LibA is
> cloned by the user and generated/built OR an INSTALL of LibA.
>
> Perhaps I should not be using `get_target_property` to get the a library's
> include directory? Either way, would like some guidance in solving this
> issue.
>
> Thank you,
> Saad
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions: Identifying when they're used in a custom command?

[Alan W. Irwin]

On 2018-02-19 13:03-0700 Sam Edwards wrote:


Alan,

I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
is the most essential part of what you suggested. Bah!

I tried copying in your changes verbatim and I'm still left with an output
that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
machine) and 2.8.12 (my testing VM). Does your version of CMake produce
IS_INTERROGATE=1 with your changes?


I don't want to get involved in too much further testing since the
overview of what you are attempting to do with generator expressions
is beyond my expertise.  However, I did build the following simple
project (with CMake-3.6.2)

cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test NONE)
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
  IS_INTERROGATE 1)
get_target_property(target_interrogate depending_target IS_INTERROGATE)
message(STATUS "target_interrogate = ${target_interrogate}")

The results were

-- target_interrogate = 1
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/software/plplot/HEAD/build_dir/test_build

That result confirms that if you set that property on a custom target,
then that value is accessible via get_target_property (as expected).
So I don't know why that value is not currently accessible to you with
generator expressions, but for what it is worth (since this is beyond
my CMake expertise) I think it should be.  Anyhow, to debug this
further I suggest you simplify your test case even further (similar to
above) and compare generator expression results with
get_target_property results to try and understand what is going
on with the generator expression version.



The rationale behind 2.8.12 is this is the version that ships with Ubuntu
Trusty and will probably be what's present if a user is simply told to
"install CMake" - although 3.5.1 is also available on that platform under
the cmake3 package, so I might be able to justify a minimum version of
either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
have to bring it up with the project maintainer to see, but in any case
we're trying to follow a "stick with the same minimum version until we
encounter a bug we can't work around, then bump the minimum to the version
that fixes that bug" approach.


I would take the opposite approach, i.e., develop for the latest CMake, and
then once that completely works, push the minimum version to smaller
values to see how far you can get before you run into any difficulties.

In any case, I would definitely avoid early CMake 3 versions such as
3.0.1 for the reasons I mentioned.  I hauled that around on my back
for a while by working around its bugs with the PLplot build system,
but it was quite a lot of effort, and that build system became
somewhat simpler once I bumped the minimum cmake version to 3.6.2.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions: Identifying when they're used in a custom command?

[Elvis Stansvik]

2018-02-19 21:03 GMT+01:00 Sam Edwards :
> Alan,
>
> I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
> is the most essential part of what you suggested. Bah!
>
> I tried copying in your changes verbatim and I'm still left with an output
> that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
> machine) and 2.8.12 (my testing VM). Does your version of CMake produce
> IS_INTERROGATE=1 with your changes?
>
> The rationale behind 2.8.12 is this is the version that ships with Ubuntu
> Trusty and will probably be what's present if a user is simply told to
> "install CMake" - although 3.5.1 is also available on that platform under
> the cmake3 package, so I might be able to justify a minimum version of
> either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
> have to bring it up with the project maintainer to see, but in any case
> we're trying to follow a "stick with the same minimum version until we
> encounter a bug we can't work around, then bump the minimum to the version
> that fixes that bug" approach.
>
> Thanks for your suggestions,

Hm, I'm not sure I'm enough of a CMake ninja to understand this, but,
when I read in the docs:

$
Value of the property prop on the target on which the generator
expression is evaluated.

And then see:

set_target_properties(base_target PROPERTIES
  IS_INTERROGATE 0
  INTERFACE_INCLUDE_DIRECTORIES
"IS_INTERROGATE=$>")

Correct me if I'm wrong, but I think that
$ here will always be the value of
IS_INTERROGATE on the base_target (so 0), since that's the target on
which the generator expression is evaluated? Or?

I think that's where the 0 in your output comes from in the end?

Elvis

> Sam
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions: Identifying when they're used in a custom command?

[Sam Edwards]

Alan,

I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
is the most essential part of what you suggested. Bah!

I tried copying in your changes verbatim and I'm still left with an output
that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
machine) and 2.8.12 (my testing VM). Does your version of CMake produce
IS_INTERROGATE=1 with your changes?

The rationale behind 2.8.12 is this is the version that ships with Ubuntu
Trusty and will probably be what's present if a user is simply told to
"install CMake" - although 3.5.1 is also available on that platform under
the cmake3 package, so I might be able to justify a minimum version of
either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
have to bring it up with the project maintainer to see, but in any case
we're trying to follow a "stick with the same minimum version until we
encounter a bug we can't work around, then bump the minimum to the version
that fixes that bug" approach.

Thanks for your suggestions,
Sam
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions: Identifying when they're used in a custom command?

[Alan W. Irwin]

On 2018-02-18 19:47-0700 Sam Edwards wrote:


Alan,

Thanks for your help! I tried to implement that paradigm myself in a small
example CMakeLists.txt which I've attached, but the addition of a depending
custom target doesn't seem to change the context of the 'this' target. In
other words, the IS_INTERROGATE property is still read from fake_target and
not depending_target.

Could you take a look and clarify what I'm not doing quite right?


Hi Sam:

I just looked at the custom command part of it which was

add_custom_command(OUTPUT source.c
  COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$" >
source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
  IS_INTERROGATE 1)

# Compile the output
add_executable(output source.c)
# Make sure we depend on the custom target
add_dependencies(output depending_target)

I would change the above to the following:

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/source.c
  COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$" >
source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/source.c)
set_target_properties(depending_target PROPERTIES
  IS_INTERROGATE 1)

# Compile the output
add_executable(output ${CMAKE_CURRENT_BINARY_DIR}/source.c)

Here are my reasons for the suggested changes.

* Absolute path when referring to source.c.  I am not sure whether
  this is stylistic or required, but this style works for me.

* Use DEPENDS to make the custom target depend on the custom command.
  This change is essential.

* Drop add_dependency.  The typical way you let CMake know that source
code is generated is with the GENERATED property which should take
care of all dependencies.  However,
 implies to
me you do not even need to specify the GENERATED property for
${CMAKE_CURRENT_BINARY_DIR}/source.c.  So try the above and see, and
if it does not work try using the GENERATED property.

* Set a much higher minimum CMake version.  You mentioned CMake
2.8.12+ in your original post, but there are some fundamental
differences between CMake-2 and CMake-3, and in my opinion you are
just making a rod for your back if you try to make your build system
work for both.  For example, I have no idea whether the above approach
will work for 2.8.12.  Another constraint is early versions of CMake-3 were
frankly buggy.  So I use a minimum version of CMake-3.6.2 for all my
build systems, and that works well for me.  Note all modern
Linux distributions, Cygwin, MinGW-w64/MSYS2, HomeBrew, MacPorts, and
Fink all provide that version of CMake or higher, and Kitware provides
CMake for that version and higher for MSVC as well so that choice of minimum
CMake version should inconvenience very few of your potential users.

I hope these suggested changes help you toward your broader goal.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions: Identifying when they're used in a custom command?

[Sam Edwards]

Alan,

Thanks for your help! I tried to implement that paradigm myself in a small
example CMakeLists.txt which I've attached, but the addition of a depending
custom target doesn't seem to change the context of the 'this' target. In
other words, the IS_INTERROGATE property is still read from fake_target and
not depending_target.

Could you take a look and clarify what I'm not doing quite right?

Best,
Sam

On Sun, Feb 18, 2018 at 3:09 PM, Alan W. Irwin 
wrote:

> On 2018-02-18 03:49-0700 Sam Edwards wrote:
>
> However, when it came time to actually set this IS_INTERROGATE property, I
>> could find no way to apply it to a custom command. I guess this makes
>> sense
>> - custom commands aren't targets, after all. But I couldn't convert my
>> custom command to a custom target, because it produces a C++ source file
>> and I need to use OUTPUT to let CMake know where that source file comes
>> from, and you can't use OUTPUT and TARGET together in add_custom_command.
>>
>
> Hi Sam:
>
> It's quite common for each custom command to have a corresponding
> custom target that DEPENDS on the OUTPUT of the custom command.  So
> building the target part of that pair means the custom command is
> executed *only if* the OUTPUT from it is out of date.
>
> If you used that paradigm for the custom commands you refer to
> above (where each such custom command is paired with a unique target
> via the DEPENDS of the latter) could you not set the IS_INTERROGATE
> property for the custom target part of of each pair whenever that
> property is relevant?
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
cmake_minimum_required(VERSION 2.8.12)

# Create a fake target, with a property with a generator expression
add_custom_target(base_target)
set_target_properties(base_target PROPERTIES
  IS_INTERROGATE 0
  INTERFACE_INCLUDE_DIRECTORIES 
"IS_INTERROGATE=$>")

add_custom_target(fake_target)
set_target_properties(fake_target PROPERTIES
  IS_INTERROGATE 0
  INTERFACE_INCLUDE_DIRECTORIES 
"$")

# This is the script that we run with the custom command which generates our
# C source code.
set(script_path "${CMAKE_CURRENT_BINARY_DIR}/make_printer_program.py")
FILE(WRITE "${script_path}" "
import sys

arg = sys.argv[1]

print('#include ')
print('int main() { puts(\"%s\"); return 0; }' % arg)
")

# Run the generation script
find_package(PythonInterp QUIET REQUIRED)
add_custom_command(OUTPUT source.c
  COMMAND "${PYTHON_EXECUTABLE}" "${script_path}" 
"$" > source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
  IS_INTERROGATE 1)

# Compile the output
add_executable(output source.c)
# Make sure we depend on the custom target
add_dependencies(output depending_target)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions: Identifying when they're used in a custom command?

[Alan W. Irwin]

On 2018-02-18 03:49-0700 Sam Edwards wrote:


However, when it came time to actually set this IS_INTERROGATE property, I
could find no way to apply it to a custom command. I guess this makes sense
- custom commands aren't targets, after all. But I couldn't convert my
custom command to a custom target, because it produces a C++ source file
and I need to use OUTPUT to let CMake know where that source file comes
from, and you can't use OUTPUT and TARGET together in add_custom_command.


Hi Sam:

It's quite common for each custom command to have a corresponding
custom target that DEPENDS on the OUTPUT of the custom command.  So
building the target part of that pair means the custom command is
executed *only if* the OUTPUT from it is out of date.

If you used that paradigm for the custom commands you refer to
above (where each such custom command is paired with a unique target
via the DEPENDS of the latter) could you not set the IS_INTERROGATE
property for the custom target part of of each pair whenever that
property is relevant?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] generator expressions

[Robert Maynard]

Hi Micha,

When using generator expressions inside target_include_directories you must
qualify all paths. Either by using absolute paths, or using one of the
helper variables that allows CMake to determine where the relative path
should be evaluated from.

This is all really well documented at:
http://www.cmake.org/cmake/help/v3.2/manual/cmake-buildsystem.7.html#include-directories-and-usage-requirements

On Wed, Apr 8, 2015 at 3:26 AM, Micha Renner 
wrote:

> Hi,
>
> I try to understand the concept of generator expressions with little
> avail.
>
> For the current project I thought, I could use them in combination with
> TARGET_INCLUDE_DIRECTORIES.
> Instead of writting
> IF(t1)
> TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1 PRIVATE
> path/to/h2)
> ELSE(t1)
> TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1)
> ENDIF(t1)
>
> it should be more elegant
>
> SET(t1 ON)
> ADD_EXECUTABLE(cTest CTest.c cTest.h)
> TARGET_INCLUDE_DIRECTORIES(cTest PRIVATE path/to/h1 $<
> $:"PRIVATE path/to/h2")
>
> Of course this creates a major disaster.
>
> --
> CMake Warning (dev) in CMakeLists.txt:
>   Policy CMP0021 is not set: Fatal error on relative paths in
>   INCLUDE_DIRECTORIES target property.  Run "cmake --help-policy
> CMP0021" for
>   policy details.  Use the cmake_policy command to set the policy and
>   suppress this warning.
>
>   Found relative path while evaluating include directories of "cTest":
>
> ""PRIVATE path/to/h2""
>
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> cmake:
> /home/gildemeister/Picture/work-c/CMakeSrc/cmake-3.2.1/Source/cmLocalGenerator.cxx:2923:
> std::string cmLocalGenerator::ConvertToRelativePath(const
> std::vector >&, const string&, bool): Assertion
> `in_remote[0] != '\"'' failed.
> Abgebrochen (Speicherabzug geschrieben)
> --
>
> Is there a way to solve this with a generator expression?
>
> Michael
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] generator-expressions + pch -> need new magic

[Evgeniy Dushistov]

I found workaround for that problem,
I add to this loop:
foreach(flag ${MY_DEFS})
 list(APPEND gcc_flags  "-D${flag}")
endforeach()

such code:
  foreach(flag ${PL_COMP_DEFS})
string(FIND ${flag} "$<" find_res)
if (find_res EQUAL 0)
  list(APPEND gcc_flags "$<$:-D$>")
else ()
  list(APPEND gcc_flags  "-D${flag}")
endif ()
  endforeach()

but may there is better solution?

On Sun, Oct 5, 2014 at 10:25 AM, Evgeniy Dushistov  wrote:
> Hi,
> in my project I used such magic code for precompiled headers support
> (gcc,clang only):
>
> #take gcc_flags from
>   ${CMAKE_CXX_FLAGS}
> ${CMAKE_CXX_FLAGS_${_build_type}}
>get_target_property(... COMPILE_FLAGS)
>  get_directory_property(...
> INCLUDE_DIRECTORIES)   foreach(flag
> ${MY_INCLUDES})
> list(APPEND gcc_flags  "-I" "${pl_flag}")
>  endforeach()
>
> get_directory_property(... COMPILE_DEFINITIONS)
> foreach(flag ${MY_DEFS})
>   list(APPEND gcc_flags  "-D${pl_flag}")
>   endforeach()
>
>get_directory_property(...
> COMPILE_DEFINITIONS_${_build_type})   add_custom_command(...
> ${gcc_flags} ...)
> All works fine, until cmake-3.0 with cmake-generator-expressions.
>  With cmake-3.0 COMPILE_DEFINITIONS return something like this:
> $<$>:QT_NO_DEBUG>
>
> This is empty string on compilation stage, not on not configuration
> stage. So "gcc" is called like this: "gcc -D" and give error.
> So question is it possible to evaluate "generator-expressions" within
> CMakeLists.txt? Or may be in cmake 3.x there another is way to extract
> compilation
> flags without such magic as above?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] generator expressions

[Andrew Fuller]

On Fri, Jun 6, 2014 at 8:43 AM, Brad King  wrote:

> On 06/06/2014 11:37 AM, Andrew Fuller wrote:
> > Should I be quoting all my generator expressions?
> > Is that the proper syntax?
>
> The CMake language does not actually know anything about generator
> expressions.  They are just strings like any other command arguments
> as far as it knows.  See the command argument syntax documentation
> here:
>
>
> http://www.cmake.org/cmake/help/v3.0/manual/cmake-language.7.html#command-arguments
>
> In order to ensure the command receives a generator expression in
> its entirety it should be double-quoted if it contains any literal
> spaces or ${var} evaluations that may have ; in them.  Otherwise
> it is not necessary to quote and sometimes looks nicer not to.  It
> is always safe to quote generator expressions though.
>
> -Brad
>
>
I agree it often looks better without the quotes.  But correctness trumps
aesthetics.  I guess where I went astray was that it appeared to work
unquoted when doing a simple test with add_executable and so I standardized
on unquoted which then came back to bite me unexpectedly later.  I think
I'm understanding better the situation thanks to your explanation combined
with that link.

I shall quote them all!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] generator expressions

[Brad King]

On 06/06/2014 11:37 AM, Andrew Fuller wrote:
> Should I be quoting all my generator expressions?
> Is that the proper syntax?

The CMake language does not actually know anything about generator
expressions.  They are just strings like any other command arguments
as far as it knows.  See the command argument syntax documentation
here:

 
http://www.cmake.org/cmake/help/v3.0/manual/cmake-language.7.html#command-arguments

In order to ensure the command receives a generator expression in
its entirety it should be double-quoted if it contains any literal
spaces or ${var} evaluations that may have ; in them.  Otherwise
it is not necessary to quote and sometimes looks nicer not to.  It
is always safe to quote generator expressions though.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] generator expressions

[Andrew Fuller]

On Fri, Jun 6, 2014 at 8:28 AM, Brad King  wrote:

> On 06/06/2014 11:07 AM, Andrew Fuller wrote:
> > On Fri, Jun 6, 2014 at 6:08 AM, Brad King  > wrote:
> >
> > I cannot reproduce these.  Can you provide a complete CMakeLists.txt
> > example please?
> >
> > Attached
>
> Thanks.  I meant to quote the whole outermost $<> expression as one
> argument.  Also you are missing some closing '>' in the last block.
> For example:
>
> -$<$:${_windowsLibListL}>
> -$<$:$
> +"$<$:${_windowsLibListL}>"
> +"$<$:$>"
>
> -Brad
>
>
Oh my!  I wouldn't have thought of doing that.  Oops about the missed
closing '>'; with the closing > but not adjusting the quotes still gives
the syntax error.

But adding quotes around the entire thing ...  now that works!  (even for
test #2 where I'm not using $.  That's an easy fix for my project.

Should I be quoting all my generator expressions?  Is that the proper
syntax?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] generator expressions

[Brad King]

On 06/06/2014 11:07 AM, Andrew Fuller wrote:
> On Fri, Jun 6, 2014 at 6:08 AM, Brad King  > wrote:
> 
> I cannot reproduce these.  Can you provide a complete CMakeLists.txt
> example please?
>  
> Attached

Thanks.  I meant to quote the whole outermost $<> expression as one
argument.  Also you are missing some closing '>' in the last block.
For example:

-$<$:${_windowsLibListL}>
-$<$:$
+"$<$:${_windowsLibListL}>"
+"$<$:$>"

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] generator expressions

[Brad King]

On 06/05/2014 04:44 PM, Andrew Fuller wrote:
> target_link_libraries( my_target PRIVATE
>  $<$:win.1;win.2>
>  $<$:lin.1;lin.2> )
> gives a link line of -lwin.2 -llin.1 -llin.2 
[snip]
>  $<$:$>
[snip]
> It appears in this instance as though the list is being split before
> the generator expression is being evaluated.

I cannot reproduce these.  Can you provide a complete CMakeLists.txt
example please?

For the JOIN expression with a space, you could quote the whole
thing to make sure the space is recognized as part of the argument.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions in custom commands

[Michael Wild]

On 6. Sep, 2010, at 20:58 , David Cole wrote:

> On Mon, Sep 6, 2010 at 2:34 PM, Michael Wild  wrote:
> 
>> Hi all
>> 
>> add_test(NAME  COMMAND ) has these cool generator
>> expressions, where one can use e.g $ to obtain the file
>> name of the target. I wondered whether there was a reason as to why this
>> feature isn't available in custom commands, especially in the TARGET form,
>> where it would be really useful in a POST_BUILD command.
>> 
>> Michael
> 
> Hi Michael,
> 
> Same reason as always: too many features, not enough time.
> 
> We would love to extend that sort of syntax to custom commands as well. It
> has simply not been the focus of anybody's time or money budget yet.
> 
> 
> Cheers,
> David


The only acceptable answer ;-)

In case somebody gets bored: http://cmake.org/Bug/view.php?id=11209

--
There is always a well-known solution to every human problem -- neat, 
plausible, and wrong.
H. L. Mencken



PGP.sig
Description: This is a digitally signed message part
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Generator expressions in custom commands

[David Cole]

On Mon, Sep 6, 2010 at 2:34 PM, Michael Wild  wrote:

> Hi all
>
> add_test(NAME  COMMAND ) has these cool generator
> expressions, where one can use e.g $ to obtain the file
> name of the target. I wondered whether there was a reason as to why this
> feature isn't available in custom commands, especially in the TARGET form,
> where it would be really useful in a POST_BUILD command.
>
> Michael
>
> --
> There is always a well-known solution to every human problem -- neat,
> plausible, and wrong.
> H. L. Mencken
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



Hi Michael,

Same reason as always: too many features, not enough time.

We would love to extend that sort of syntax to custom commands as well. It
has simply not been the focus of anybody's time or money budget yet.


Cheers,
David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake