<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 2:46 AM, 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"><br><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_4774154171255584754gmail-"><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></span><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" target="_blank">https://cmake.org/cmake/help/<wbr>v3.9/manual/cmake-buildsystem.<wbr>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 class="gmail-m_4774154171255584754gmail-h5"><div> </div></div></div></div></div></div></blockquote></div><br></div><div class="gmail_extra">Yes absolutely the inheritance mech is folder based and is the very problem.  This is the very problem with LINK_DIRECTORIES, INCLUDE_DIRECTORIES, and flags I initial had in 2009 and from from the current state of things 8 years later it appears that not much is changed.  I have been able to use the interface mech to get around what was my use-case for my "project/config" macros, but from what your saying I will only get so far before the CMake design rope around my ankle staked out at the start line ends in me falling flat on my face.<br><br></div><div class="gmail_extra">It is refreshing to see there is at least someone else out there that understands this core problem in CMake, wish Kitware did, Boost.Build had/has no such problem.  We as humans learn form our mistakes... over and over again... every generation... sadly they are the same mistakes.  You state IMHO, but there are no opinions involved on my end... it is simply a FACT that CMake design is flawed.  Personally I am way past opinions.  It appears that I must begin Honey Badgering ;-) the devs until this is finally fixed or just fix it myself.<br><br></div><div class="gmail_extra">If you have some CMake code that you now does now work say in a test proj I can test to see what fully does not work then I can add this to my issues when I begin the feature request / request for sanity.<br><br>Also I will likely post another inherited build props specific post so 
that these problems and be discussed specifically and can be refereed to
 by devs for the why.<br><br></div><div class="gmail_extra">I don't know if you have a current macro end-around solution, but if you want I could post my project/config macros on git hub.  You would likely have to mod those to get add_project_configuration  to accept all your build props to be inherited.  Ideally I long for a core solution in CMake and thought / hoped I had it with interface.  Thanks for crushing my hopes and  dreams :-).  <br><br><br></div><div class="gmail_extra">At one time I did have a compiler_config in my code so your needs for CXX Flags may just work with below (it's commented out in my current proj, but the place holder is still there)<br></div><div class="gmail_extra"><br>add_project_configuration(<br>    compiler_config<br>#    CXX_FLAGS_INIT<br>#        "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR "<br>#    CXX_FLAGS_DEBUG<br>#        "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od /Gm "<br>#    CXX_FLAGS_DEBUG_INIT<br>#        "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od "<br>#<br>#    C_FLAGS_DEBUG<br>#        "/D_DEBUG /MDd  /Zi  /Ob0 /Od  "<br>#    C_FLAGS_DEBUG_INIT<br>#        "/D_DEBUG /MDd /Zi  /Ob0 /Od "<br>#<br>#    CXX_FLAGS_MINSIZEREL_INIT<br>#        "/MD /O1 /Ob1 /D NDEBUG"<br>#    CXX_FLAGS_RELEASE_INIT<br>#        "/MD /O2 /Ob2 /D NDEBUG"<br>#    CXX_FLAGS_RELWITHDEBINFO_INIT<br>#        "/MD /Zi /O2 /Ob1 /D NDEBUG"<br>#<br>#    C_FLAGS_INIT<br>#        "/DWIN32 /D_WINDOWS /W3 /Zm1000"<br>#    C_FLAGS_MINSIZEREL_INIT<br>#        "/MD /O1 /Ob1 /D NDEBUG"<br>#    C_FLAGS_RELEASE_INIT<br>#        "/MD /O2 /Ob2 /D NDEBUG"<br>#    C_FLAGS_RELWITHDEBINFO_INIT<br>#        "/MD /Zi /O2 /Ob1 /D NDEBUG"<br>#    # the following line should break the build when it is working!! Right now it is not as all FLAGS are not working.<br>#    C_STANDARD_LIBRARIES_INIT<br>#        "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib mylib.lib"<br>#    COMPILE_FLAGS /DGOOP_123<br>    LINKER_LANGUAGE<br>        CXX<br>)<br><br></div><div class="gmail_extra">Then the config props can be inherited as:<br></div><div class="gmail_extra"><br>add_project_library( <br>    GP_Loader<br>    INHERIT_CONFIGURATIONS<br>        compiler_config<br>        mex_config<br>        utility_config   <br>        boost_config   <br>    CPP_SOURCES <br>        GP_Loader.cpp<br>        ${GP_LINK}<br>    INSTALL_DIRECTORIES<br>#        ${CMAKE_CURRENT_SOURCE_DIR}<br>        bin<br>        ${TOP}/source/Matlab/lib<br>    LIB_SUFFIX<br>        ${MEX_LIB_EXT}<br>)<br><br></div><div class="gmail_extra">Certainly much less verbose that vanilla CMake goop.  If interested let me know, but like I said may require some work to get them to do what you need as I only exposed enough CMake to get what I needed and do not handle every CMake command.  I refer to it as Super Awesome Projects (SAP), but like anything created in a vacuum I am certain once the seal it cracked and exposed to the community it sucks to some degree or another. I just could not come up with a working acronym for SUCKER ;-)  <br><br></div><div class="gmail_extra">Why oh why cruel world is this the state of things?  Sigh<br></div><div class="gmail_extra"><br></div></div>