On Thu, Aug 24, 2017 at 2:46 AM, Jean-Michaël Celerier < jeanmichael.celer...@gmail.com> wrote:
> > 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. >> >> 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. >> >> > I think that there is just no mechanism for "inherited build properties". > From the docs (https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem. > 7.html#interface-libraries), INTERFACE targets seems to be meant for > header-only libraries. > > 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 set(CMAKE_CXX_FLAGS "-my-flags > ${CMAKE_CXX_FLAGS}") every time. > > 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. 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. 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. 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. 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 :-). 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) add_project_configuration( compiler_config # CXX_FLAGS_INIT # "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR " # CXX_FLAGS_DEBUG # "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od /Gm " # CXX_FLAGS_DEBUG_INIT # "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od " # # C_FLAGS_DEBUG # "/D_DEBUG /MDd /Zi /Ob0 /Od " # C_FLAGS_DEBUG_INIT # "/D_DEBUG /MDd /Zi /Ob0 /Od " # # CXX_FLAGS_MINSIZEREL_INIT # "/MD /O1 /Ob1 /D NDEBUG" # CXX_FLAGS_RELEASE_INIT # "/MD /O2 /Ob2 /D NDEBUG" # CXX_FLAGS_RELWITHDEBINFO_INIT # "/MD /Zi /O2 /Ob1 /D NDEBUG" # # C_FLAGS_INIT # "/DWIN32 /D_WINDOWS /W3 /Zm1000" # C_FLAGS_MINSIZEREL_INIT # "/MD /O1 /Ob1 /D NDEBUG" # C_FLAGS_RELEASE_INIT # "/MD /O2 /Ob2 /D NDEBUG" # C_FLAGS_RELWITHDEBINFO_INIT # "/MD /Zi /O2 /Ob1 /D NDEBUG" # # the following line should break the build when it is working!! Right now it is not as all FLAGS are not working. # C_STANDARD_LIBRARIES_INIT # "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib mylib.lib" # COMPILE_FLAGS /DGOOP_123 LINKER_LANGUAGE CXX ) Then the config props can be inherited as: add_project_library( GP_Loader INHERIT_CONFIGURATIONS compiler_config mex_config utility_config boost_config CPP_SOURCES GP_Loader.cpp ${GP_LINK} INSTALL_DIRECTORIES # ${CMAKE_CURRENT_SOURCE_DIR} bin ${TOP}/source/Matlab/lib LIB_SUFFIX ${MEX_LIB_EXT} ) 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 ;-) Why oh why cruel world is this the state of things? Sigh
-- 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