<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Ok got it sorry to hear that certainly because, as soon as I hear something that would be useful somehow I end up needing it the next day. So sorry for us both.<br><br></div>From what your are saying (and I will take your word for it) the CMake has a another problem in not implementing "inherited build properties" correctly. That is of course if that is what CMake is after with add_library( targ INTERFACE) in the first place. <br><br></div></div></blockquote><div><br></div><div>I think that there is just no mechanism for "inherited build properties". From the docs (<a href="https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries">https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries</a>), INTERFACE targets seems to be meant for header-only libraries.</div><div><br></div><div>The "inheritance" mechanism in CMake is mainly setting variables in a given folder, but this is imho not flexible enough, and leads to problems when you want to use your library as a subfolder of another since you don't have an easy way to overwrite "child" variables from a parent scope unless the child scope carefully did <span style="font-family:monospace,monospace">set(CMAKE_CXX_FLAGS "-my-flags ${CMAKE_CXX_FLAGS}") </span>every time.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for the heads up on yet more CMake does not do correctly.<br></div><br>I am now climbing upon my "inherited build properties" soap box. It's kinda slippery up here.<br><div><div><div><div><div class="gmail_extra"><div><div class="gmail-h5"><br><div class="gmail_quote">On Wed, Aug 23, 2017 at 4:57 PM, Jean-Michaël Celerier <span dir="ltr"><<a href="mailto:jeanmichael.celerier@gmail.com" target="_blank">jeanmichael.celerier@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span class="gmail-m_1485427244019009027gmail-">> Does that work for your needs?<br><br></span>Sadly, no (but thanks!). While this is enough for the arguably common use case of include directories, compile flags, etc... there are plenty of things that won't work with this approach.<br><br></div>e.g. none of this works for instance:<br><br>project(foo)<br><br>add_library(blah INTERFACE)<br>set_property(TARGET blah PROPERTY SUFFIX ".mxe")<br>set_property(TARGET blah PROPERTY CXX_STANDARD 14)<br>set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail-m_1485427244019009027gmail-m_-2934129959805964593gmail_signature"><div dir="ltr"><div><br></div><div><font color="#783f04"><br></font></div><div><font size="2" face="arial, helvetica, sans-serif" color="#134f5c">-------</font></div><font size="2" face="arial, helvetica, sans-serif" color="#134f5c">Jean-Michaël Celerier</font><div><font size="2" face="arial, helvetica, sans-serif" color="#134f5c"><a href="http://www.jcelerier.name" target="_blank">http://www.jcelerier.name</a></font></div></div></div></div>
<br><div class="gmail_quote"><div><div class="gmail-m_1485427244019009027gmail-h5">On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <span dir="ltr"><<a href="mailto:bitminer@gmail.com" target="_blank">bitminer@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_1485427244019009027gmail-h5"><div dir="ltr"><pre>So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes:<br></pre><pre>@Jean-Michaël Celerier <br><br></pre><pre>-- snip --<span><br>><i> - Says that custom functions such as add_{project}_library shouldn't be
</i></span>used and function definitions should be used as little as possible. Except
this just leads to extremely verbose CMakeLists where repeated properties
are defined again and again and again.
-- snip --</pre><pre>Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake.<br><br>1) They were used to get CMake to support the concept of "inherited build properties". <br></pre><pre>2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call<br></pre><pre><br>-- snip --
I also never understood how to handle this.<br>-- snip --</pre><pre>I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. <br></pre><pre><br>-- snip --<br> I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
and the SUFFIX property on a specific set of 25 targets amongst ~100
targets. What am I to do ?
* set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
would be harder to set / unset on specific targets).
* calling target_compile_options(...) 25 times ... well I mean, everyone
knows it's bad to duplicate code. Especially if the change is meant to be
only when a specific option() is enabled, or for debugging purposes
* creating a function that would set the correct flags, etc and then call
this function for each target is apparently "not modern CMake" either.
* creating and linking to "dummy" INTERFACE targets with the flags and
properties I want have an awful lot of limitations
So what is the right course of actions here ?
-- snip --<br><br></pre><pre>I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library)<br></pre><pre>I just posted this which may help:<br><br><a href="https://cmake.org/pipermail/cmake/2017-August/066119.html" target="_blank">https://cmake.org/pipermail/cm<wbr>ake/2017-August/066119.html</a><br><br>-- snip --<span><br>Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin
for $software", "target Bar is an integration test" and set per-group
options, flags, properties, etc. Like
add_group(PluginGroup)
target_compile_definitions(Plu</span><wbr>ginGroup -DBLAH)
set_property(GROUP PluginGroup PROPERTIES /* whatever in
cmake-properties*/)
set_group(myTarget PluginGroup) // applies everything to the target
-- snip --<br><br></pre><pre>I won't have all the syntax for what your trying but possibly try:<br><br></pre><pre>add_library( PluginGroupInterface INTERFACE)<br>target_compile_definitions(Plu<wbr>ginGroupInterface -DBLAH)
set_property(GROUP PluginGroup PROPERTIES /* whatever in
cmake-properties*/)
<br></pre><pre>I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way.<br></pre><pre>then...<br><br></pre><pre>add_executable( myTarget )<br></pre><pre>target_link_libraries(<br> myTarget<br> PluginGroupInterface<br>)<br></pre><pre>Does that work for your needs?<br></pre><pre><br><br>-- snip --
Best,
-------
Jean-Michaël Celerier<br><br>-- snip --</pre></div>
<br></div></div><span class="gmail-m_1485427244019009027gmail-">--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMak<wbr>e_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/su<wbr>pport.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/co<wbr>nsulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/tr<wbr>aining.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/cmake</a><br></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="gmail-HOEnZb"><font color="#888888">-- <br><div class="gmail-m_1485427244019009027gmail_signature">Brian J. Davis<br></div>
</font></span></div></div></div></div></div></div>
</blockquote></div><br></div></div>