Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote: >> I've implemented it in the tll-includes-defines branch in my clone. I've >> only tested it manually though. > > Yes, that looks good. Please add tests covering each case: I've pushed it again to my clone. Once the fix-target-property-commands topic is in master, we can rebase it if needed and get it merged to next. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja + Windows CE
On 01/26/2013 12:33 PM, Patrick Gansterer wrote: > to compile WindowsCE C++ project with Ninja I need the attached patch > applied. One problem with this patch is that it moves the initialization of C and CXX languages until after the RC initialization which tries to match the location of the C/CXX compilers. Have a look at these: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3a1f727 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6547f369 Peter, can you explain why this is needed for Ninja but not the other generators? Why does the logic belong in that method? Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/30/2013 03:15 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>>> I've implemented it in the tll-includes-defines branch in my clone. I've
>>> only tested it manually though.
>>
>> Yes, that looks good. Please add tests covering each case:
>
> I've pushed it again to my clone.
>
> Once the fix-target-property-commands topic is in master, we can rebase it
> if needed and get it merged to next.
I just tried your branch with a simple test case:
--
cmake_minimum_required(VERSION 2.8.10.20130129)
project(FOO C)
set(CMAKE_INSTALL_PREFIX "${FOO_BINARY_DIR}/root")
add_library(foo SHARED foo.c)
target_include_directories(foo PUBLIC
$
$/include>
)
add_library(bar SHARED bar.c)
#set(m m) # uncommenting breaks this
target_link_libraries(bar LINK_PUBLIC foo ${m})
get_property(iface TARGET bar PROPERTY INTERFACE_INCLUDE_DIRECTORIES)
message(STATUS "bar.INTERFACE_INCLUDE_DIRECTORIES = [${iface}]")
export(TARGETS bar foo FILE Targets.cmake)
install(TARGETS bar foo DESTINATION lib EXPORT Foo)
install(EXPORT Foo DESTINATION lib/cmake/foo)
--
It works, but then uncommenting the marked line to tll a non-target
produces:
-- bar.INTERFACE_INCLUDE_DIRECTORIES =
[$;$<$:$>]
CMake Error at CMakeLists.txt:16 (export):
$ requires its first parameter to be a reachable
target.
The TARGET_PROPERTY errors out even though TARGET_DEFINED:m should
be false.
Also, will the non-target expressions added by tll be preprocessed out
during export()/install(EXPORT)?
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote: > On 01/30/2013 03:15 AM, Stephen Kelly wrote: >> Brad King wrote: >> I've implemented it in the tll-includes-defines branch in my clone. I've only tested it manually though. >>> >>> Yes, that looks good. Please add tests covering each case: >> >> I've pushed it again to my clone. >> >> Once the fix-target-property-commands topic is in master, we can rebase >> it if needed and get it merged to next. > > I just tried your branch with a simple test case: > It works, but then uncommenting the marked line to tll a non-target > produces: > > -- bar.INTERFACE_INCLUDE_DIRECTORIES = > [$; $<$:$>] > CMake Error at CMakeLists.txt:16 (export): > $ requires its first parameter to be a reachable > target. That was fixed in fix-TARGET_PROPERTY-extraction, which was merged yesterday. Now that fix-target-property-commands was merged to master, I've rebased tll-includes-defines to master and your testcase works. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/30/2013 10:57 AM, Stephen Kelly wrote:
> Now that fix-target-property-commands was merged to master, I've rebased
> tll-includes-defines to master and your testcase works.
Thanks. However, now it leaks out all non-targets referenced by tll
as giant strings in the exported interfaces:
if(NOT ${CMAKE_FIND_PACKAGE_NAME}_NO_INTERFACES)
set_target_properties(bar PROPERTIES
INTERFACE_COMPILE_DEFINITIONS
"$;$<$:$>"
INTERFACE_INCLUDE_DIRECTORIES
"$;$<$:$>"
)
endif()
This is not acceptable. We need to recognize when something was added
by tll and was not a target and remove it from the non-linking interfaces.
Can export() and install(EXPORT) do partial evaluation to remove these?
We can document that $ has scope only in the current
project and will be processed away during export. I do not think we
want an upstream interface modifying its behavior based on the mere
presence of an arbitrary target in the downstream anyway.
Other thoughts:
* The $ expression should evaluate as an error if
it is ever reached by any path except install(EXPORT). Otherwise
the empty string in $/somewhere is unlikely to
do the right thing.
* If exported interfaces were partially evaluated then $
could be handled with a real evaluation instead of string replacement.
* Transitive linking is handled in C++ code rather than in generator
expressions so there is no bloat in the LINK_LIBRARIES properties
for non-target elements like the above. Perhaps we can have a special
generator expression that has context-sensitive evaluation e.g.
$
tll() would add this to COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES
properties where it would be evaluated to get relevant target interface
properties. In other contexts it would be an empty string (or error?).
It could be preprocessed out during export and replaced by nothing for
non-targets or the relevant $ for targets.
* To optimize the large strings these interfaces generate, perhaps
properties can be represented in general as compiled generator
expressions that do not directly store their original strings but
have references to pieces of them and can reconstruct them.
This can be done later though.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote:
> On 01/30/2013 10:57 AM, Stephen Kelly wrote:
>> Now that fix-target-property-commands was merged to master, I've rebased
>> tll-includes-defines to master and your testcase works.
>
> Thanks. However, now it leaks out all non-targets referenced by tll
> as giant strings in the exported interfaces:
>
> if(NOT ${CMAKE_FIND_PACKAGE_NAME}_NO_INTERFACES)
>set_target_properties(bar PROPERTIES
> INTERFACE_COMPILE_DEFINITIONS
> "$;
$<$:$>"
> INTERFACE_INCLUDE_DIRECTORIES
> "$;
$<$:$>"
>)
> endif()
>
> This is not acceptable. We need to recognize when something was added
> by tll and was not a target and remove it from the non-linking interfaces.
> Can export() and install(EXPORT) do partial evaluation to remove these?
As preprocessing is how things like that are done so far, I think using
preprocessing is the more straightforward way to do this at the moment. At
some point in the future we can see if partial evaluation is possible. It
would be possible to do in a later release if it is possible at all.
> We can document that $ has scope only in the current
> project and will be processed away during export. I do not think we
> want an upstream interface modifying its behavior based on the mere
> presence of an arbitrary target in the downstream anyway.
>
> Other thoughts:
>
> * The $ expression should evaluate as an error if
> it is ever reached by any path except install(EXPORT). Otherwise
> the empty string in $/somewhere is unlikely to
> do the right thing.
Right. I've added a patch to that effect now.
>
> * If exported interfaces were partially evaluated then $
> could be handled with a real evaluation instead of string replacement.
>
> * Transitive linking is handled in C++ code rather than in generator
> expressions so there is no bloat in the LINK_LIBRARIES properties
> for non-target elements like the above. Perhaps we can have a special
> generator expression that has context-sensitive evaluation e.g.
>
> $
That makes sense to me. I don't have time to do it right now though. Maybe I
can do it later.
>
> tll() would add this to COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES
> properties where it would be evaluated to get relevant target interface
> properties. In other contexts it would be an empty string (or error?).
> It could be preprocessed out during export and replaced by nothing for
> non-targets or the relevant $ for targets.
>
> * To optimize the large strings these interfaces generate, perhaps
> properties can be represented in general as compiled generator
> expressions that do not directly store their original strings but
> have references to pieces of them and can reconstruct them.
> This can be done later though.
Perhaps. We'll have to keep the fact that not all properties can contain
generator expressions, but that should be possible. All for the future
though.
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/30/2013 12:09 PM, Stephen Kelly wrote: >> This is not acceptable. We need to recognize when something was added >> by tll and was not a target and remove it from the non-linking interfaces. >> Can export() and install(EXPORT) do partial evaluation to remove these? > > As preprocessing is how things like that are done so far, I think using > preprocessing is the more straightforward way to do this at the moment. At > some point in the future we can see if partial evaluation is possible. It > would be possible to do in a later release if it is possible at all. Okay, if preprocessing is sufficient to get rid of those then go for it. >> We can document that $ has scope only in the current >> project and will be processed away during export. I do not think we >> want an upstream interface modifying its behavior based on the mere >> presence of an arbitrary target in the downstream anyway. Thoughts on this behavior? Another thought is to have tll() only append includes/defines if the target is already defined at the call site and otherwise do nothing. When I previously pointed out the need for handling not-yet-defined targets I did not realize the cost. We could even go as far as not adding the generator expression to INCLUDE_DIRECTORIES if the target dependency does not have an INTERFACE_INCLUDE_DIRECTORIES already defined too (and similarly for COMPILE_DEFINITIONS). Advantages: * Very little overhead for non-target arguments * Very little overhead for targets without interfaces * Works in the motivating case of using targets imported from an upstream Disadvantages: * Does not work automatically for circular dependencies. I think the disadvantage is okay because circular dependencies are a less common case and one can always make it work by writing out the generator expression manually. We should not make everyone pay the cost for supporting circular interfaces when few are using them. We can't even define circular interfaces through tll() anyway except for static libraries. >> * The $ expression should evaluate as an error if >> it is ever reached by any path except install(EXPORT). Otherwise >> the empty string in $/somewhere is unlikely to >> do the right thing. > > Right. I've added a patch to that effect now. Thanks. >> * Transitive linking is handled in C++ code rather than in generator >> expressions so there is no bloat in the LINK_LIBRARIES properties >> for non-target elements like the above. Perhaps we can have a special >> generator expression that has context-sensitive evaluation e.g. >> >> $ > > That makes sense to me. I don't have time to do it right now though. Maybe I > can do it later. Perhaps there is no need for it if we use the simpler approach above. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
