Interface Libraries allow include directories but not link directories.. Why?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2
Why does:
allow include directories via

target_include_directories(INTERFACE)

which if we look at property scope:

https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html

Why is include_directories at target resolution while link_directories is at directory resolution.

link_directories is a property on a directory which if I recalled correctly I complained about many many moons ago (circa 2009) when I first realized this.  I did not understand this logic then and don't understand this logic now.  Someone what to give me the recipe for the CMake cool-aid so I can mix that up, drink it down, and re-read the doc and finally come to terms with this.  Or could the powers that be redesign CMake to make sense.  At the time I wrapped this nonsense in a macro and pretended it did not happen ... now I am rewriting my project for "new" CMake and still don't get this.




--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Robert Maynard
Usage of link_directories is discouraged, and was part of the reason
why a target based option was not added. As the documentation for
link_directories states "Note that this command is rarely necessary.
Library locations returned by find_package() and find_library() are
absolute paths. Pass these absolute library file paths directly to the
target_link_libraries() command. CMake will ensure the linker finds
them."

On Mon, Aug 21, 2017 at 8:17 PM, Brian Davis <[hidden email]> wrote:

> Why does:
>
> Interface Libraries
> https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3
>
> allow include directories via
>
> target_include_directories(INTERFACE)
>
> but not link_directories
>
> https://cmake.org/cmake/help/latest/prop_dir/LINK_DIRECTORIES.html?highlight=link_directories
>
> which if we look at property scope:
>
> https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html
>
> Why is include_directories at target resolution while link_directories is at
> directory resolution.
>
> link_directories is a property on a directory which if I recalled correctly
> I complained about many many moons ago (circa 2009) when I first realized
> this.  I did not understand this logic then and don't understand this logic
> now.  Someone what to give me the recipe for the CMake cool-aid so I can mix
> that up, drink it down, and re-read the doc and finally come to terms with
> this.  Or could the powers that be redesign CMake to make sense.  At the
> time I wrapped this nonsense in a macro and pretended it did not happen ...
> now I am rewriting my project for "new" CMake and still don't get this.
>
>
>
>
> --
>
> 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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2
C comments

On Tue, Aug 22, 2017 at 8:01 AM, Robert Maynard <[hidden email]> wrote:
Usage of link_directories is discouraged, and was part of the reason
why a target based option was not added. As the documentation for
link_directories states "Note that this command is rarely necessary.
Library locations returned by find_package() and find_library() are
absolute paths. Pass these absolute library file paths directly to the
target_link_libraries() command. CMake will ensure the linker finds
them."


Oh the horror.  We are not expected to have abs paths to our libs to ensure "CMake finds them" vs supporting link library directories which all compilers support for some reason.  I mean hey maybe CMake could support / expose functionality of the underlying tools to the user in a way and means that make sense and let them decide if abs paths or use of link libs dir is appropriate.  I know which one I would choose.  Is it really that difficult to make Link_directories a target specific property?

It's as though tying a remote control to a grandmother so as to "ensure" she can turn on the TV is also a good idea.

I hope I never understand this logic.

Has any one read my post on ITK and use of abs paths where there is a 50 char limit imposed on where itk is built due to command line limitations on windows for the build.  I am starting to understand how and why I now have to build itk at C:/itk... I asked ITK if I should just build at c:\ but they stated graciously something to the affect that I could  use those extra 3 chars... boy was I happy then!
and reassess logic of abs paths

Snips in line here for convenience:


-- snip --

But ITK is no great example either
as on windows has a limit due to path length limiting on where ITK can be
build (build dir) I think it's something like 56 characters (resulting in
build paths outside the project like C:\itk\src\ITK-4.8.1)  and I have
stated my aggravation regarding this on ITK's user forum.   I must be
joking right?  well from ITK root CMakeLists.txt file:

if( CMAKE_HOST_WIN32 )

  string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n )
  if( n GREATER 50 )
    message(
      FATAL_ERROR
      "ITK source code directory path length is too long (${n} > 50)."
      "Please move the ITK source code directory to a directory with a
shorter path."
      )
  endif()

Sadly no and .. ok so it's 50.

-- snip --

I would certainly like to hear a defense of this "logic". I like to say that I discourage insanity.




On Mon, Aug 21, 2017 at 8:17 PM, Brian Davis <[hidden email]> wrote:
> Why does:
>
> Interface Libraries
> https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3
>
> allow include directories via
>
> target_include_directories(INTERFACE)
>
> but not link_directories
>
> https://cmake.org/cmake/help/latest/prop_dir/LINK_DIRECTORIES.html?highlight=link_directories
>
> which if we look at property scope:
>
> https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html
>
> Why is include_directories at target resolution while link_directories is at
> directory resolution.
>
> link_directories is a property on a directory which if I recalled correctly
> I complained about many many moons ago (circa 2009) when I first realized
> this.  I did not understand this logic then and don't understand this logic
> now.  Someone what to give me the recipe for the CMake cool-aid so I can mix
> that up, drink it down, and re-read the doc and finally come to terms with
> this.  Or could the powers that be redesign CMake to make sense.  At the
> time I wrapped this nonsense in a macro and pretended it did not happen ...
> now I am rewriting my project for "new" CMake and still don't get this.
>
>
>
>
> --
>
> 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



--
Brian J. Davis

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2
Upon further reflection the abs paths for every lib is absolutely not defensible. 

1) Pass only the short lib name to target_link_libraries
2) Add absolute path to future target_link_directories if you must

Then it's one (1) long path on the command line string and not N long paths fore each lib

I seriously can't believe in 2017 I am actually having this conversation.  

Did I miss something here or does Kitware really mean to have package maintainers spec

target_link_libraries(
    targ
    INTERFACE
    C:\projects\lib1\install\lib\lib1
​    C:\projects\lib1\install\lib\lib2
​    C:\projects\lib1\install\lib\lib3
)

and not

​target_link_libraries(
    targ
    INTERFACE
    lib1
    lib2
    lib3
)

target_link_directories( targ INTERFACE C:\projects\lib1\install\lib )

Does Kitware understand the length problem on command line tools and get the difference I am trying to convey here?  As far as cmd line would go "one of these is not like the other", but would have same effect.   If implemented for projs like ITK maybe I could build is a place other than C:\

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2
In reply to this post by Brian Davis-2

and provide future

​target_link_directories(
   targ
   INTERFACE
   debug ${TOP}/build/x64/Debug/Libraries/
   optimized ${TOP}/build/x64/Release/Libraries/
)

with debug / optimized / general capability

then targets could support multiple debug / release dirs even if CMake (CMAKE_INSTALL_PREFIX) can't (ie no CMAKE_INSTALL_PREFIX_<CONFIG> capability)

If anyone is looking at those dirs and wondering *why* (as I often do)... I need CMake in mixed mode with CMake generated projs and imported existing vcxproj files.

if provided I could then targ link dirs, include dirs, and interface the libs from a position of relative sanity or at least the white jacket with wrap around arms tied in the back would be a little looser to the fit.




--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Lectem

No you're not meant to specify paths yourself, you should just use find_library.
Check how modules such as FindTIFF.cmake are implemented.


Le mar. 22 août 2017 à 19:05, Brian Davis <[hidden email]> a écrit :

and provide future

​target_link_directories(
   targ
   INTERFACE
   debug ${TOP}/build/x64/Debug/Libraries/
   optimized ${TOP}/build/x64/Release/Libraries/
)

with debug / optimized / general capability

then targets could support multiple debug / release dirs even if CMake (CMAKE_INSTALL_PREFIX) can't (ie no CMAKE_INSTALL_PREFIX_<CONFIG> capability)

If anyone is looking at those dirs and wondering *why* (as I often do)... I need CMake in mixed mode with CMake generated projs and imported existing vcxproj files.

if provided I could then targ link dirs, include dirs, and interface the libs from a position of relative sanity or at least the white jacket with wrap around arms tied in the back would be a little looser to the fit.



--

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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2


On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire <[hidden email]> wrote:

No you're not meant to specify paths yourself, you should just use find_library.
Check how modules such as FindTIFF.cmake are implemented.


Please doc in CMake all the things I am "meant to" so as I can live inside that happy little bubble world.

Did I not just provide a perfectly rational reason why a crazed end user may want set lib path... err.... themselves

/LIBPATH: is there for a reason in the compiler / linker sadly it appears CMake does not get this.  Clearly like the toolchain developers thought it was a good idea... hmm wonder it it had anything to do with the command line length problem?  Ahh yes must be a pesky little throwback from the days of yore.  Full paths eureka!  Nope not buying it.

It appears CMake wants to save me from myself by not allowing me to set LIBPATH.  I mean do I got this right?  If so who's going to save CMake from themselves?

Hey why not completely save me from myself and take away target_include_directories.

I find find_library (I tried it and had in the past) still yields full path for every library even if multiple libs are in same dir and is even documented as such:

https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library

"If the library found is a framework, then <VAR> will be set to the full path to the framework <fullPath>/A.framework. When a full path to a framework is used as a library, CMake will use a -framework A, and a -F<fullPath> to link the framework to the target."

When these full lib dirs are chucked at the linker .... kerpow... if large paths are used where project is located.


But hey if find_library or whatever insanity I should use would say use a parameterized variable other than what is currently:

find_library(
   MY_LIB_DEBUG
   NAMES 4DFUtilities.lib
   HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug
)

FUORO4D_UTILITY_LIB_DEBUG = C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib

but rather generate a paramaterized version:

FUORO4D_UTILITY_LIB_DEBUG = "LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries"

(above is goop I have had to resort to <at this rate may still have to> in CMake and VARARG macros for some  resemblance of inherited build properties prior to interface libraries)

Then prior to command generation for linker *could* through the power of filtering for unique strings search all those LINK_DIRECTORY paths specifications and retain unique and set that crazy elusive, never to be gazed upon by human eyes, it-who-must-not-be-named /LIBPATH flag.  Doesn't that little cursor have enough to do with out dancing all over the place printing out full paths to libraries... I mean give the little bugger a break will ya!

Let me be clear.  There are two problems here:

1) Abs paths to link libraries causing command line length issues such as in ITK
2) Inability to set lib dirs at target resolution.  find_library which is suggested a solution to this could be *if* it did not force abs paths to libs and would rather gather up unique full paths and set /LIBPATH

There may only be one problem here.   If find_library worked as I suggest then there would be zero problems here... with the exception that CMAKE_VARIABLES such as what find_library generates are so 2.8.12 (ref: https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf) and not "Targets" and "Properties" which if we had target_link_directories... would be! (CMake could even add find capability if desired) As per my new sense of sensibilities in the new CMake era frankly I find find_library to be the old backwards way of doing this... not that it does it correctly in the first pace... never has.

And don't get me started on the FindWhatevers and CMake Packaging ... ohhh that's coming!  Consider that worm can open.... I have already started to post some bits on that insanity, the lack of direction and features in CMake (project VERSION not appending to CMAKE_INSTALL_PREFIX so as not to blast away prior installed versions), inconsistent CMake documentation (lack of lib and include dir versioning and standard location of where to put .cmake package files), and  3rd party package devs do whatever they want mantra, and the end user experience.  If CMake really wants to save me... save me from the 3rd party package developers miss use of CMake by fixing and better documenting CMake.  3rd party package devs only do what they think is right and what they can get away with based on poor doc and impl.



--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Lectem

I can't argue too much why paths or absolute on cmake as I don't know the rationale behind it is. While your point about command line limit makes sense, I feel like a system limiting command line size to this extent is dumb if it doesn't allow reading more arguments through a file. (again, I don't know the system at all).
I kinda understand your point about not being able to set the libdir per target but (might have missed it in your previous mails) I don't know what kind of project would need that. At best I would need one version of the library per configuration, which is supported.

I entirely agree with for the rest. CMake badly documenting good practices or even giving tutorials is an issue. Probably the biggest issue I found. I myself still fight after years of using and experimenting with it. This lead to a plethora of badly written cmakelists.txt or module scripts, that even people in this list still advocates without understanding the problems behind it. Even some tutorial series found on github.com or used by coverage websites do it wrong.

At the moment the only reference I trust is Daniel's presentation and some of the internal cmake scripts.

While not solving your problem, I documented most of my findings in this small template /reference https://github.com/Lectem/cpp-boilerplate (which might still do things the wrong way)


Le mer. 23 août 2017 à 02:14, Brian Davis <[hidden email]> a écrit :
On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire <[hidden email]> wrote:

No you're not meant to specify paths yourself, you should just use find_library.
Check how modules such as FindTIFF.cmake are implemented.


Please doc in CMake all the things I am "meant to" so as I can live inside that happy little bubble world.

Did I not just provide a perfectly rational reason why a crazed end user may want set lib path... err.... themselves

/LIBPATH: is there for a reason in the compiler / linker sadly it appears CMake does not get this.  Clearly like the toolchain developers thought it was a good idea... hmm wonder it it had anything to do with the command line length problem?  Ahh yes must be a pesky little throwback from the days of yore.  Full paths eureka!  Nope not buying it.

It appears CMake wants to save me from myself by not allowing me to set LIBPATH.  I mean do I got this right?  If so who's going to save CMake from themselves?

Hey why not completely save me from myself and take away target_include_directories.

I find find_library (I tried it and had in the past) still yields full path for every library even if multiple libs are in same dir and is even documented as such:

https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library

"If the library found is a framework, then <VAR> will be set to the full path to the framework <fullPath>/A.framework. When a full path to a framework is used as a library, CMake will use a -framework A, and a -F<fullPath> to link the framework to the target."

When these full lib dirs are chucked at the linker .... kerpow... if large paths are used where project is located.


But hey if find_library or whatever insanity I should use would say use a parameterized variable other than what is currently:

find_library(
   MY_LIB_DEBUG
   NAMES 4DFUtilities.lib
   HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug
)

FUORO4D_UTILITY_LIB_DEBUG = C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib

but rather generate a paramaterized version:

FUORO4D_UTILITY_LIB_DEBUG = "LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries"

(above is goop I have had to resort to <at this rate may still have to> in CMake and VARARG macros for some  resemblance of inherited build properties prior to interface libraries)

Then prior to command generation for linker *could* through the power of filtering for unique strings search all those LINK_DIRECTORY paths specifications and retain unique and set that crazy elusive, never to be gazed upon by human eyes, it-who-must-not-be-named /LIBPATH flag.  Doesn't that little cursor have enough to do with out dancing all over the place printing out full paths to libraries... I mean give the little bugger a break will ya!

Let me be clear.  There are two problems here:

1) Abs paths to link libraries causing command line length issues such as in ITK
2) Inability to set lib dirs at target resolution.  find_library which is suggested a solution to this could be *if* it did not force abs paths to libs and would rather gather up unique full paths and set /LIBPATH

There may only be one problem here.   If find_library worked as I suggest then there would be zero problems here... with the exception that CMAKE_VARIABLES such as what find_library generates are so 2.8.12 (ref: https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf) and not "Targets" and "Properties" which if we had target_link_directories... would be! (CMake could even add find capability if desired) As per my new sense of sensibilities in the new CMake era frankly I find find_library to be the old backwards way of doing this... not that it does it correctly in the first pace... never has.

And don't get me started on the FindWhatevers and CMake Packaging ... ohhh that's coming!  Consider that worm can open.... I have already started to post some bits on that insanity, the lack of direction and features in CMake (project VERSION not appending to CMAKE_INSTALL_PREFIX so as not to blast away prior installed versions), inconsistent CMake documentation (lack of lib and include dir versioning and standard location of where to put .cmake package files), and  3rd party package devs do whatever they want mantra, and the end user experience.  If CMake really wants to save me... save me from the 3rd party package developers miss use of CMake by fixing and better documenting CMake.  3rd party package devs only do what they think is right and what they can get away with based on poor doc and impl.


--

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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Nicholas Devenish
On Wed, Aug 23, 2017 at 8:07 AM, Clément Gregoire <[hidden email]> wrote:

I entirely agree with for the rest. CMake badly documenting good practices or even giving tutorials is an issue. Probably the biggest issue I found. I myself still fight after years of using and experimenting with it. This lead to a plethora of badly written cmakelists.txt or module scripts, that even people in this list still advocates without understanding the problems behind it. Even some tutorial series found on github.com or used by coverage websites do it wrong.

I definitely agree that it's extremely hard to find documentation on good ways to do things, and I've personally suspected for a while that the total lack of public information on good/proper/stable way of writing cmakelists is reflective of an internal situation where there isn't really agreement on the way things should be done, and that the notion of "Modern CMake" as something concrete is an entirely public mental construction. (even interface targets - see how very few FindX modules use them, and of those that do, the documentation is always buried right at the bottom. But then even basic FindX things like, how it should handle repeat-inclusion, seems to be left to discretion of single modules).

Most of the (good/even existing) public documentation I've seen are on personal blogs, for people who've obviously come onto a project using CMake, built up required knowledge, and then moved on a year or two later. And I guess that in general people migrating large projects don't or can't publicly document the process.

Maybe I'm wrong, and e.g. paying for consulting gives you the very best advice on the best way of using modern features in complex situations. But I haven't seen a lot of evidence for it.

At the moment the only reference I trust is Daniel's presentation

Whilst it gives a reasonable overview, even Daniel's presentation I find rather misleading and (intentionally?) vague on several points, e.g. off the top of my head:
- Advocates scripts being usable standalone and also includable themselves. Gives almost no suggestion on how to do this or the many problems that can arise (I'd love this to be reasonable without writing completely unidiomatic code).
- Says that custom functions such as add_{project}_library shouldn't be 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.
- But simultaneously advocates rewriting internal functions using the (undocumented?) '_' feature to access "previous definitions". Uses this as one of the few examples of one of the steps as a method to allow a script to change behaviour if being included.
- In general makes lots of mandates without providing any suggestions how/why they should be followed
- His solution to complex external libraries being hard to use is for them to "just use CMake". This is really offputting.

I'm certain his grasp of these problems is great, and appreciate it's just a single presentation, but *personally* (and I emphasise this is the way that *I* view it) find his presentation style hard to follow and it doesn't leave me with much confidence of the contents.

I suspect this is just a side-effect of having only one real source for these things, that was never meant to end up as a communities single reference.



Much of the rest of this thread seems to be undirected rhetorical rant, so I don't suspect expanding it would lead anywhere.

Nick

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Uwe Koloska
On 23.08.2017 11:44, Nicholas Devenish wrote:
> - But simultaneously advocates rewriting internal functions using the
> (undocumented?) '_' feature to access "previous definitions". Uses this
> as one of the few examples of one of the steps as a method to allow a
> script to change behaviour if being included.

I have raised an issue on this undocumented behavior:
https://gitlab.kitware.com/cmake/cmake/issues/17199

Regards
Uwe

--
Dipl.-Ing. Uwe Koloska
Chief Software Evangelist

voice INTER connect GmbH               Tel +49 351 407 526 50
Ammonstraße 35                         Fax +49 351 407 526 55
01067 Dresden - Germany                www.voiceinterconnect.de

Geschäftsführung:  Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil
Eingetragen im Handelsregister:   Amtsgericht Dresden HRB 19466

voiceINTERconnect www.voiceinterconnect.de
                     ... smart speech applications from Germany
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Jean-Michaël Celerier
> - Says that custom functions such as add_{project}_library shouldn't be 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.

I also never understood how to handle this.

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 ?

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(PluginGroup -DBLAH)
    set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
    set_group(myTarget PluginGroup) // applies everything to the target

Best,

-------
Jean-Michaël Celerier

On Wed, Aug 23, 2017 at 1:30 PM, Uwe Koloska <[hidden email]> wrote:
On 23.08.2017 11:44, Nicholas Devenish wrote:
> - But simultaneously advocates rewriting internal functions using the
> (undocumented?) '_' feature to access "previous definitions". Uses this
> as one of the few examples of one of the steps as a method to allow a
> script to change behaviour if being included.

I have raised an issue on this undocumented behavior:
https://gitlab.kitware.com/cmake/cmake/issues/17199

Regards
Uwe

--
Dipl.-Ing. Uwe Koloska
Chief Software Evangelist

voice INTER connect GmbH               Tel <a href="tel:%2B49%20351%20407%20526%2050" value="+4935140752650" target="_blank">+49 351 407 526 50
Ammonstraße 35                         Fax <a href="tel:%2B49%20351%20407%20526%2055" value="+4935140752655" target="_blank">+49 351 407 526 55
01067 Dresden - Germany                www.voiceinterconnect.de

Geschäftsführung:  Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil
Eingetragen im Handelsregister:   Amtsgericht Dresden HRB 19466

voiceINTERconnect www.voiceinterconnect.de
                     ... smart speech applications from Germany
--

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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Eric Noulard


2017-08-23 14:10 GMT+02:00 Jean-Michaël Celerier <[hidden email]>:
> - Says that custom functions such as add_{project}_library shouldn't be 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.

I also never understood how to handle this.

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 ?

I have some similar need.
 

* 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

Why is it not "modern" ? You can leverage meta-informations offered by CMake in DIRECTORY and TARGET properties.

My solution is close to this one, I have written one macro (let's call it myproj_sanitize) which takes as input
an inclusion REGEX for exe, an inclusion REGEX for lib, an exclusion REGEX for exe/lib.
So that you only have a single call (near the end of the main CMakeLists.txt where I know every targets have been defined)

myproj_sanitize(
    EXCLUDE_EXE_REGEX ""
    INCLUDE_EXE_REGEX ""
    EXCLUDE_LIB_REGEX ""
    INCLUDE_LIB_REGEX ""
              )

The algorihtm of this macros is simple:

S1) collect all SHARED and STATUS LIBRARY and EXECUTABLES targets
      by 
      examining the BUILDSYSTEM_TARGETS directory property
      and looping over all directories from the main one.
      At the end of this step I have 2 lists one for executable one for library

S2) apply exclusion and inclusion regexes for the one which are not empty.

S3) Call add_sanitizer (from https://github.com/arsenm/sanitizers-cmake)
      on the remaining targets.

I can can easily share the code of the step S1 of the macro. Once we have a mean
to get the list of concerned targets the remaining part is easy.

I was afraid of the collect processing time because the concerned project has 500+ libraries
and 800+ executables but  this is done in a couple of seconds and this is only done
when compiling in "sanitize" mode which is not ON by default.

.
* 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 ?

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(PluginGroup -DBLAH)
    set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
    set_group(myTarget PluginGroup) // applies everything to the target

I think this approach is already possible with not so much CMake scripting:

group_add(PluginGroup) --> create a bunch of global properties for internal group machinery.

G_PluginGroup_targets --> the list of targets belonging to the group
G_PluginGroup_compile_definitions
G_PluginGroup_properties --> the list of (property,value) pairs for the group

group_compile_definitions(PluginGroup -DBLAH) append to G_PluginGroup_compile_definitions
group_set_properties(PluginGroup PROPERTIES /* whatever in cmake-properties*/) append to G_PluginGroup_properties

group_set(TARGETS myTarget1 myTarget2) // applies previously defined group things to the concerned targets.

The "only" limitation would be that you have to define the meta-informations for the groups before using group_set on any
targets OR you need group_process macro called neat the end of the main CMakeLists.txt

--
Eric

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Eric Noulard


2017-08-23 15:28 GMT+02:00 Clément Gregoire <[hidden email]>:
    set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)

    set_group(myTarget PluginGroup) // applies everything to the target

Isn't it the same as having a custom target/library for the group and linking it with transitive properties ?

You mean an INTERFACE library?

For a simple set of targets properties like compile flags, probably yes.
If the set of properties to be applied to the group (of targets) contains more information than the one
conveyed through an INTERFACE library no.

For example property "C_STANDARD"
is not conveyed by transitive linking/compiling.

INTERFACE library convey "only" INTERFACE_xxxx properties to targets linking to them.

Eric
 

2017-08-23 14:51 GMT+02:00 Eric Noulard <[hidden email]>:


2017-08-23 14:10 GMT+02:00 Jean-Michaël Celerier <[hidden email]>:
> - Says that custom functions such as add_{project}_library shouldn't be 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.

I also never understood how to handle this.

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 ?

I have some similar need.
 

* 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

Why is it not "modern" ? You can leverage meta-informations offered by CMake in DIRECTORY and TARGET properties.

My solution is close to this one, I have written one macro (let's call it myproj_sanitize) which takes as input
an inclusion REGEX for exe, an inclusion REGEX for lib, an exclusion REGEX for exe/lib.
So that you only have a single call (near the end of the main CMakeLists.txt where I know every targets have been defined)

myproj_sanitize(
    EXCLUDE_EXE_REGEX ""
    INCLUDE_EXE_REGEX ""
    EXCLUDE_LIB_REGEX ""
    INCLUDE_LIB_REGEX ""
              )

The algorihtm of this macros is simple:

S1) collect all SHARED and STATUS LIBRARY and EXECUTABLES targets
      by 
      examining the BUILDSYSTEM_TARGETS directory property
      and looping over all directories from the main one.
      At the end of this step I have 2 lists one for executable one for library

S2) apply exclusion and inclusion regexes for the one which are not empty.

S3) Call add_sanitizer (from https://github.com/arsenm/sanitizers-cmake)
      on the remaining targets.

I can can easily share the code of the step S1 of the macro. Once we have a mean
to get the list of concerned targets the remaining part is easy.

I was afraid of the collect processing time because the concerned project has 500+ libraries
and 800+ executables but  this is done in a couple of seconds and this is only done
when compiling in "sanitize" mode which is not ON by default.

.
* 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 ?

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(PluginGroup -DBLAH)
    set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
    set_group(myTarget PluginGroup) // applies everything to the target

I think this approach is already possible with not so much CMake scripting:

group_add(PluginGroup) --> create a bunch of global properties for internal group machinery.

G_PluginGroup_targets --> the list of targets belonging to the group
G_PluginGroup_compile_definitions
G_PluginGroup_properties --> the list of (property,value) pairs for the group

group_compile_definitions(PluginGroup -DBLAH) append to G_PluginGroup_compile_definitions
group_set_properties(PluginGroup PROPERTIES /* whatever in cmake-properties*/) append to G_PluginGroup_properties

group_set(TARGETS myTarget1 myTarget2) // applies previously defined group things to the concerned targets.

The "only" limitation would be that you have to define the meta-informations for the groups before using group_set on any
targets OR you need group_process macro called neat the end of the main CMakeLists.txt

--
Eric

--

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




--
Eric

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2
In reply to this post by Lectem


On Wed, Aug 23, 2017 at 2:07 AM, Clément Gregoire <[hidden email]> wrote:

I can't argue too much why paths or absolute on cmake as I don't know the rationale behind it is. While your point about command line limit makes sense, I feel like a system limiting command line size to this extent is dumb if it doesn't allow reading more arguments through a file. (again, I don't know the system at all).

My command line problem experience stems from two problems:

1) building ITK as a superproject/superbuild within my project and from within VMTK which also used ITK in a superbuild.. well and building VMTK superbuild inside my superbuild project.  Yes it's a Russian dolls/onion of superbuilds.  Boy I would also like to comment on those problems, but that will be for a different post.

2) My somewhat successful (I say somewhat as appose to ideal) ExternalProject_Add build of boost from git repo where setting boost build command at the cmd prompt vs within VS studio.  I had to resort to CMD prompt to eak out those last bits-o-chars.
 
Ahh yes here it is from my CMake files:

    # Does not work as command path length is too long.
    #    add_custom_target(
    #       boost_build_target
    #       "echo ${BUILD_BOOST_CMD}; ${BUILD_BOOST_CMD}"
    #       WORKING_DIRECTORY ${BOOST_SOURCE_DIR} )


I kinda understand your point about not being able to set the libdir per target but (might have missed it in your previous mails) I don't know what kind of project would need that. At best I would need one version of the library per configuration, which is supported.

Ok here goes as I would really like people to understand my problems with the current CMake impl then possibly I could be awed by the logic of CMake and stand corrected .... or possibly ... just possibly I am correct and CMake could change course.

First off there is some inconsistencies in the logic of the design / impl of CMake from my perspective if we look at the new target/properties and statements from 3rd parties (pdf mentioned earlier) as to the direction /logic of CMake. 

1) find_library forces user down a path of abs paths and does not allow the return of the path in the event the user wants to pass the path to LINK_DIRECTORIES.  Which coupled with my path problems I chose/forced not to use find_library.  Ok so like I said I could build of off C:\ so I'll give CMake that.  CMake forces full abs paths for every lib specified even for those of us who don't want it / can't use it in find_library.  Why not have find_library return two (2) VARS one for lib and other for path and provide option to user and state the WHY the user should choose abs paths.  Then I could argue the WHY problem directly, but still have an out for LINK_DIRECTORIES/LIBPATH use.  However CMake forced the abs full  path on every lib issue and has not provide a *good* mechanism to the alternative. 

2) find_library is as I am sure CMake would agree is not under the target/property new design.  Say the target is targ and the property is the library path, but find_library is all or nothing and a CMake variable.  Where CMake variables if pdf is to be believed is not under the new CMake "don't use variables" design philosophy.  Not that I know what the actual Design of CMake is or should be and I would certainly like to hear that and have CMake resolve this discrepancy.

3) In VS (well in Linux for that matter) can set include paths and I can set LIBPATH(s) on targets.   In CMake I can set include_directories on targets but not lib paths.  However I can get around this and do by using LIBRARY_PATH which is at the directory level.  CMake should expose always the underlying abilities of the tools to the user and guide to the best use for sure, but never force... and I am seemingly forced to do an illogical end-around (go to directory scope to set what should be a target property).

As to:

"I kinda understand your point about not being able to set the libdir per target but (might have missed it in your previous mails) I don't know what kind of project would need that"

How about projects for which boost and find_package(Boost) (<- Beware of caps when using boost and find_package yes it's case sensitive)  is used?

#+-----------------------------------------------------------------------------
set(
        BOOST_LIBS
        Boost::boost
        Boost::system
        Boost::date_time
        Boost::filesystem
        Boost::serialization
        )

add_library( boost_interface INTERFACE )
target_include_directories(
    boost_interface
    INTERFACE
        ${BOOST_INCLUDE_DIR}
)

target_link_libraries(
    boost_interface
    INTERFACE
        ${BOOST_LIBS}
)

#+-----------------------------------------------------------------------------

And yes all my boost use needs at least those libs other opts to create another interface for inheritance based on other lib use is certainly possible.

I have a mixed mode CMake generated vsprojs and existing vsprojs files where include_external_msproject is used for some projects:

#------------------------------------------------------------------------------
add_library( 4duiplugin_interface INTERFACE )

target_include_directories(
    4duiplugin_interface
    INTERFACE
         ${4DUI_PLUGIN_DIR}
)



add_library( utilities_interface INTERFACE )

target_link_libraries(
    utilities_interface
    INTERFACE
    optimized ${TOP}/build/x64/Release/Libraries/Utilities.lib
    debug ${TOP}/build/x64/Debug/Libraries/Utilities.lib
)

target_include_directories(
    utilities_interface
    INTERFACE
     ${4DFUTILITIES_INCLUDE_DIR}
)


add_library( dicomreader_interface INTERFACE )

target_link_libraries(
   dicomreader_interface
    INTERFACE
    optimized ${TOP}/build/x64/Release/Libraries/DicomReader.lib
    debug ${TOP}/build/x64/Debug/Libraries/DicomReader.lib
)
#------------------------------------------------------------------------------

Why cannot I set say:

target_library_directories(   
    utilities_interface
    INTERFACE
    optimized ${TOP}/build/x64/Release/Libraries
    debug ${TOP}/build/x64/Debug/Libraries
)

Note use of only directories above and use of unavailable target_library_directory to set LIBPATH where it could search out duplicate paths before chucking at the linker.  find_library certainly can't do it as is uses abs paths.  While abs paths are used above and certainly could by target/property'izing LIB_DR this could give CMake an "out" to the command line length problem by filtering for unique before setting LIBPATH.  Hey CMake could even provide an ABSOLUTE command in target_link_directories and state some gibberish as to how/why absolute long paths for every library is better... not that I buy it now and will not then either.


Then used sometime later:

target_link_libraries(
    ${SOME_LIB}
    4dfutilities_interface
    4dfdicomreader_interface
    cuda_sdk_interface
    boost_interface
    shaderslib_interface
#    vtk_interface
    vmtk_interface
)


Also cmake 3.7/3.8//3.9 started to support CUDA as a first class language.  Now the question: do I use:

project( prjname CXX CUDA)

or

find_package(CUDA 9.0)

or both?

well I in the spirit of new CMake I chose project.

But now the question... how does CMake 3.9 support finding the cudart.lib (or cudafft) or say libs in the SDK( such as gluts or glews or FreeImage).  Well the answer as far as I can tell ... it does not.  It's not documented and so I checked out the 3.9 source and I am reverse engineering it to figure out how it works or what works and does not and what is impled/not impled.  So what's a CMake 3.+'er (me) to do?  (well after crying as to the state of things)  I could:

# -----------------------------------------------------------------------------
add_library( cuda_toolkit_interface INTERFACE )
target_include_directories(
    cuda_toolkit_interface
    INTERFACE
         ${CUDA_TOOLKIT_LIB_DIR}
)

target_link_libraries(
    cuda_toolkit_interface
    INTERFACE
        cuda_rt_static   
)

add_library( cuda_sdk_interface INTERFACE )
target_include_directories(
    cuda_sdk_interface
    INTERFACE
        ${CUDA_SDK_INCLUDE_DIR}
)
# -----------------------------------------------------------------------------

then when linking a target that needs said inherited build properties I could:

target_link_libraries(
    rendertest
    PRIVATE
    cuda_toolkit_interface
    cuda_sdk_interface
    boost_interface
    opengl_interface
    shaderslib
)

say for any target needing cuda.


I entirely agree with for the rest. CMake badly documenting good practices or even giving tutorials is an issue. Probably the biggest issue I found. I myself still fight after years of using and experimenting with it. This lead to a plethora of badly written cmakelists.txt or module scripts, that even people in this list still advocates without understanding the problems behind it. Even some tutorial series found on github.com or used by coverage websites do it wrong.

Yes glad and at the same time sorry to hear someone has had some of the same experience I have had and I say these things in hopes CMake will get fixed/better, but hey again maybe I am wrong.  

I have been rewriting my CMake files to support new target/properties and for the most part I no longer have to use my parameterized variables and custom project macros (add_project_config, add_project_executable, and add_project_library - which sadly had to use LINK_DIRECTORIES)  with VAR ARGS parsing to get the concept of "inherited build properties" based on my jam experience from Boost.Build... so kudos to CMake for that if only for LIBPATH an hence the post. 

Sadly I knew the answer even before I asked the question based on using CMake since 2009 and even giving a teaching lecture on it to promote it's use where I also promoted inherited build properties even though CMake at at the time did not support it directly.

 

At the moment the only reference I trust is Daniel's presentation and some of the internal cmake scripts.

While not solving your problem, I documented most of my findings in this small template /reference https://github.com/Lectem/cpp-boilerplate (which might still do things the wrong way)


Yes just at line 22 I already have a problem.... that did not take long.

1) project does not specify VERSION and project name  "CPP-BoilerPlate" does not incorporate ver string such as


SET(MAJOR_VERSION 1)
SET(MINOR_VERSION 2)
SET(MAINTENANCE_VERSION 3)

and then

project( "CPP-BoilerPlate-${MAJOR_VERSION}.${MINOR_VERSION}.${MAINTENANCE_VERSION}" VERSION ${MAJOR_VERSION}.${MINOR_VERSION}.${MAINTENANCE_VERSION}
C CXX)

as what is CMAKE_INSTALL_PREFIX by default across versions?  What does VERSION do in project?  Well I know what it does not affect... yep CMAKE_INSTALL_PREFIX.  Try compiling and installing on Windows multiple versions of this project see what you get.

3rd party package developers end up blasting away prior versions... maybe by design but who knows in my experience (IME).

Again though not as though CMake discusses "best practices" here or make VERSION actually do something useful as say append to CMAKE_INSTALL_PREFIX
${MAJOR_VERSION}.${MINOR_VERSION}.${MAINTENANCE_VERSION}.

Thanks for the link/resource I take form it any good bits I can use at 157 lines it is not all that realistic of a full blown project with multiple dependencies mixed mode VS projs and CMake gen projs and other real world shenanigans.


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2
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:
@Jean-Michaël Celerier 

-- snip --
> - Says that custom functions such as add_{project}_library shouldn't be 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 --
Yes add_project_library were my own and in the process of being deprecated.  These were geared directly at two problems in cmake.

1) They were used to get CMake to support the concept of "inherited build properties".
2) As you stated and is still a problem the verbosity of CMake.  Where IMO much could be collaped into one call

-- snip -- I also never understood how to handle this.
-- snip --
I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. 

-- snip --
 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 --

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)
I just posted this which may help:

https://cmake.org/pipermail/cmake/2017-August/066119.html

-- snip --
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(PluginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target -- snip --

I won't have all the syntax for what your trying but possibly try:

add_library( PluginGroupInterface INTERFACE)
target_compile_definitions(PluginGroupInterface -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
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.
then...

add_executable( myTarget )
target_link_libraries(
myTarget
PluginGroupInterface
)
Does that work for your needs?


-- snip -- Best, ------- Jean-Michaël Celerier

-- snip --

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Jean-Michaël Celerier
> Does that work for your needs?

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.

e.g. none of this works for instance:

project(foo)

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")




-------
Jean-Michaël Celerier

On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <[hidden email]> wrote:
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:
@Jean-Michaël Celerier 

-- snip --
> - Says that custom functions such as add_{project}_library shouldn't be
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 --
Yes add_project_library were my own and in the process of being deprecated.  These were geared directly at two problems in cmake.

1) They were used to get CMake to support the concept of "inherited build properties".
2) As you stated and is still a problem the verbosity of CMake.  Where IMO much could be collaped into one call

-- snip -- I also never understood how to handle this.
-- snip --
I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. 

-- snip --
 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 --

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)
I just posted this which may help:

https://cmake.org/pipermail/cmake/2017-August/066119.html

-- snip --
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
ginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target -- snip --

I won't have all the syntax for what your trying but possibly try:

add_library( PluginGroupInterface INTERFACE)
target_compile_definitions(PluginGroupInterface -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
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.
then...

add_executable( myTarget )
target_link_libraries(
myTarget
PluginGroupInterface
)
Does that work for your needs?


-- snip -- Best, ------- Jean-Michaël Celerier

-- snip --

--

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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2

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.  

Thanks for the heads up on yet more CMake does not do correctly.

I am now climbing upon my "inherited build properties" soap box.  It's kinda slippery up here.

On Wed, Aug 23, 2017 at 4:57 PM, Jean-Michaël Celerier <[hidden email]> wrote:
> Does that work for your needs?

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.

e.g. none of this works for instance:

project(foo)

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")




-------
Jean-Michaël Celerier

On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <[hidden email]> wrote:
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:
@Jean-Michaël Celerier 

-- snip --
> - Says that custom functions such as add_{project}_library shouldn't be
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 --
Yes add_project_library were my own and in the process of being deprecated.  These were geared directly at two problems in cmake.

1) They were used to get CMake to support the concept of "inherited build properties".
2) As you stated and is still a problem the verbosity of CMake.  Where IMO much could be collaped into one call

-- snip -- I also never understood how to handle this.
-- snip --
I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. 

-- snip --
 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 --

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)
I just posted this which may help:

https://cmake.org/pipermail/cmake/2017-August/066119.html

-- snip --
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
ginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target -- snip --

I won't have all the syntax for what your trying but possibly try:

add_library( PluginGroupInterface INTERFACE)
target_compile_definitions(PluginGroupInterface -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
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.
then...

add_executable( myTarget )
target_link_libraries(
myTarget
PluginGroupInterface
)
Does that work for your needs?


-- snip -- Best, ------- Jean-Michaël Celerier

-- snip --

--

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




--
Brian J. Davis

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Jean-Michaël Celerier

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.
 
Thanks for the heads up on yet more CMake does not do correctly.

I am now climbing upon my "inherited build properties" soap box.  It's kinda slippery up here.

On Wed, Aug 23, 2017 at 4:57 PM, Jean-Michaël Celerier <[hidden email]> wrote:
> Does that work for your needs?

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.

e.g. none of this works for instance:

project(foo)

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")




-------
Jean-Michaël Celerier

On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis <[hidden email]> wrote:
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:
@Jean-Michaël Celerier 

-- snip --
> - Says that custom functions such as add_{project}_library shouldn't be
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 --
Yes add_project_library were my own and in the process of being deprecated.  These were geared directly at two problems in cmake.

1) They were used to get CMake to support the concept of "inherited build properties".
2) As you stated and is still a problem the verbosity of CMake.  Where IMO much could be collaped into one call

-- snip -- I also never understood how to handle this.
-- snip --
I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. 

-- snip --
 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 --

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)
I just posted this which may help:

https://cmake.org/pipermail/cmake/2017-August/066119.html

-- snip --
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
ginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target -- snip --

I won't have all the syntax for what your trying but possibly try:

add_library( PluginGroupInterface INTERFACE)
target_compile_definitions(PluginGroupInterface -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/)
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.
then...

add_executable( myTarget )
target_link_libraries(
myTarget
PluginGroupInterface
)
Does that work for your needs?


-- snip -- Best, ------- Jean-Michaël Celerier

-- snip --

--

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




--
Brian J. Davis


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Interface Libraries allow include directories but not link directories.. Why?

Brian Davis-2


On Thu, Aug 24, 2017 at 2:46 AM, Jean-Michaël Celerier <[hidden email]> 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