CMake - CMake Digest, Vol 160, Issue 69

Send CMake mailing list submissions to cmake@cmake.org To subscribe or unsubscribe via the World Wide Web, visit https://cmake.org or, via email, send a message with subject or body 'help' to cmake-request@cmake.org You can reach the person managing the list at cmake-owner@cmake.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CMake digest..." Today's Topics: 1. Re: Interface Libraries allow include directories but not link directories.. Why? (Brian Davis) 2. Best practice for modifying search path for find_package() (Robert Dailey) 3. Inherited Build Properties: Is this the intent of add_library Interface Libraries? (Brian Davis) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Aug 2017 12:26:57 -0500 From: Brian Davis To: Jean-Micha?l Celerier Cc: cmake Mailing List Subject: Re: [CMake] Interface Libraries allow include directories but not link directories.. Why? Message-ID: Content-Type: text/plain; charset="utf-8" On Thu, Aug 24, 2017 at 2:46 AM, Jean-Micha?l Celerier < jeanmichael.celerier@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. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: To: CMake Subject: [CMake] Best practice for modifying search path for find_package() Message-ID: Content-Type: text/plain; charset="UTF-8" So I have a "super build" CMake script that runs a series of ExternalProject_Add() functions to execute builds of various third party libraries and install them to a path relative to the parent project's CMAKE_BINARY_DIR. Once the parent project generation occurs, it is expected to do a series of find_package() commands to locate the packages installed by the previous super build. What is the best way to intercept the find_package() search paths to prioritize searching to the custom relative root directory managed by the super build? Based on the documentation for find_package()[1], seems like CMAKE_PREFIX_PATH might be the best way (set it as a normal variable, not a cache variable) inside the CMake scripts prior to the find_package() invocations (which are done indirectly by other CMake scripts I do not manage and cannot change). Although, the usage intent for CMAKE_PREFIX_PATH seems to be documented differently than how I plan to use it. Any advice? [1]: https://cmake.org ------------------------------ Message: 3 Date: Thu, 24 Aug 2017 17:17:08 -0500 From: Brian Davis To: cmake Mailing List Subject: [CMake] Inherited Build Properties: Is this the intent of add_library Interface Libraries? Message-ID: Content-Type: text/plain; charset="utf-8" Is the goal of add_library interface libraries to add the concept of inherited build properties not dependent on the directory project inheritance structure of CMake? This is to say attach any and all cmake properties, flags, etc to a "dummy" target that can then be used by other target to "inherit" the build config of the "dummy" target. Can it be used to get around the inherent folder inheritance mechanism in CMake? Does it support all properties, flags, defs? Say for example: from: https://cmake.org add_library(blah INTERFACE) set_property(TARGET blah PROPERTY SUFFIX ".mxe") set_property(TARGET blah PROPERTY CXX_STANDARD 14) set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") without: CMake Error at CMakeLists.txt:4 (set_property): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. oh... I know my bad... lets try set_target_properties: set_target_properties( blah PROPERTIES SUFFIX ".mxe" CXX_STANDARD 14 INSTALL_RPATH "@loader_path/whatever" ) without say: CMake Error at CMakeLists.txt:20 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. CMake Error at CMakeLists.txt:20 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "CXX_STANDARD" is not allowed. CMake Error at CMakeLists.txt:20 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "INSTALL_RPATH" is not allowed. One might want to say create a template (add_project Interface Library) for all MATLAB mex libraries where say SUFFIX is .mex (above is example from others) but I would like same functionality for MATLAB Mex plugins then have plugin target inherit build props via say: add_library( mex_interface INTERFACE ) set_target_properties( mex_interface PROPERTIES SUFFIX ".mex64" LINK_FLAGS /export:mex_function ) target_link_libraries( targ mex_interface). But what do I get: CMake Error at CMakeLists.txt:31 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. CMake Error at CMakeLists.txt:31 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "LINK_FLAGS" is not allowed. Hmmm I know lets look up whitelisted in CMake doc surely that will tell me something about INTERFACE whitlisted properties. https://cmake.org Yep... bubkis as expected... in true CMake style. Since I have the CMake 3.9 source checkout as it is the only way these days to figure out what CMake does/does not.. I search that for whitelist and I'll certainly report back on how that goes. In reading: https://cmake.org "An INTERFACE library target does not directly create build output, though it may have properties set on it and it may be installed, exported and imported. Typically the INTERFACE_* properties are populated on the interface target using the commands:" correction: "it may have WHITELISTED properties that we are not going to document what they are cuz it's like super secret ... good luck!, but if you can figure out what they are by trial and error and using eclipse ide search on the checked out source tree and set on it and it may be installed, exported and imported." Huh a library that is just a interface which is not actually a library and is not a build output... could a worse term "library" been used. how about add_interface or add_config or some such not library which I can understand as an easy hack as libs are consumable by both exe's and libs, but really... library? Are command name additions at a premium in CMake? So I'll ask again what is the intent of add_project interface libraries? I am getting a pretty good idea what it's not... well i guess better idea what it isn't once find that whitelist. -------------- next part -------------- An HTML attachment was scrubbed... URL: