Even the GCC people are trying heavily to persuade you to just hide those symbols They HEAVILY affect the public API (and ABI) of a library. These values are not something the person building the project should decide.
Cmake tutorial pdf install#
Same for the install rules.ĬMAKE_CXX_VISIBILITY_PRESET and CMAKE_VISIBILITY_INLINES_HIDDEN
Cmake tutorial pdf code#
So this is adding code that needn't be there. This is pointless, as the vendoring project can just set(BUILD_SHARED_LIBS ON|OFF) prior to add_subdirectory. However, some users might need a variable determening only you library build type, so we add one As an example, find_package(Boost) definitely does not put all of the boost headers in my tree within the Qt or CLion IDEs. If that happens, the package creator is probably doing more than necessary in their FindMyLib.cmake to add sources to the parent project. I have not experienced a find_package call adding the public headers to my IDE view. Obscured behind a macro, no one has complained yet. Yea, if someone needed to type this out for every cmake it would be a nightmare. If we have a header only lib, there are no cc/cpp/c/etc files. I typically hide this from the team with a function function(AddPublicSources target_name) The find_package sorting was updated in one of those I believe the minimum required CMake version for me at the moment is 3.14 or 3.15. Might not be common, but this gets a ton of use internally for header only libraries without making a bogus compile and empty lib. I don't recall the version of CMake it was added, but it allows us to set the list of header as INTERFACE. I do happen to use PUBLIC/PRIVATE/INTERFACE religiously for source/header files though. While that may be true its rarely used by the CMake community, I don't have insight into community projects to agree or disagree. Also headers added as PUBLIC are discussed in the comments there.
Third, if you make some headers public for your library target and then I link to it using target_link_libraries(myApp yourLib) then I will see all your public headers as part of my project in my IDE which is annoying.Ĭraig Scott published an article about target_sources, I belive that you will find it interesting. Second, it's pretty hard to develop, because you need to treat each of your public header separately for build and install interface (well, because it's path changes when it is installed). That means that your team members will be confused when they find such code. I personally do not like this for several reasons.įirst, it's rarely used by CMake community (I can't remember where I saw such approach). It is merged into 'sources' for CMake to generate IDE project with the directory structure matching my repo. Variable 'public_headers' is used mainly to initialize PUBLIC_HEADER target property.
0 kommentar(er)
