[CMake] OBJECT libraries and working around lake of target_link_libraries
We recently converted some software, comprising about 300 projects, to use OBJECT libraries from SHARED libraries so we could create "conveneince" libraries that were cominations of some of the 300 projects. Not being able to use target_link_libraries with thier transitive nature made this very painful, many days of work. Supporting OBJECT libraries in target_link_libraries calls was mentioned mentioned right back here https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but sadly seems still to be on the back burner. We are faced with a project hierarchy re-org and wanted to try to automate generation of the dependencies. So we are thinking of doing the following. 1) Remove all the target_sources stuff from all CMakeLists.txt 2) Add add_dependencies calls to specify the project dependencies 3) run cmake with the --graphviz=graphviz.dot 4) Write a program that reads the resultant graphviz.dot and generate a file for each project that contain a target_sources call specifying all the dependencies for that project 5) In the CMakeLists.txt for each project include the relevant generated target_sources file 6) Rerun cmake Note the first time cmake gets run all the generated dependency files are empty so the only dependencies are those specified by add_dependencies calls. Obviously the above is a bit convoluted, although we already have a program to read and use the data in graphviz.dot file for other reason. So my question is will the above approach work and is there a better one? -- 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
Re: [CMake] Non OBJECT libraries and population of $
Thanks for the excellent suggestion. Unfortunately we can't really use for Visual Studio. The problem is that the two "add_library" calls result in two visual studio projects. The problem with this is that our generated Visual Studio solution already has 300 odd projects, using you suggestion would result in maybe 500 odd. We are already on the limit of projects in Visual Studio before the IDE becomes unusable. We could of course split the software up into multiple solutions but we are very loath to do this. However it's a great solution for our Ninja builds, so thanks. On Mon, Jul 10, 2017 at 12:09 PM, Petr Kmoch <petr.km...@gmail.com> wrote: > Hi David. > > In your particular case, you don't have build everything twice. Just make > the SHARED libraries thin wrappers around the OBJECT libraries. Like this: > > add_library(obj1 OBJECT a.cpp b.cpp ...) > add_library(lib1 SHARED $) > > add_library(obj2 OBJECT c.cpp d.cpp ...) > add_library(lib2 SHARED $) > > add_library(combined SHARED $ $) > > Petr > > On 10 July 2017 at 19:41, David Hunter <davidhunte...@gmail.com> wrote: >> >> Currently you can create an OBJECT library using "add_library( >> OBJECT ...)" this populates $ which can then >> later be used using something like >> "target_sources(name PUBLIC $)". I am wondering if >> there is some reason that $ can't be populated when >> you create a shared or static library, for instance using >> "add_library( SHARED ...)". Looking at the output the VS 2017 >> generators for "add_library( OBJECT ...)" it seems to actually >> build a static library anyway. I suspect that all the files are >> compiled to object files somewhere for both STATIC and SHARED libraries, >> if so would it not be possible to point $ as these >> object files? >> >> The reason I ask is that we have a a bunch of source code that builds >> in about 100 projects. These projects have a normal hierarchical >> dependency tree. However when distributing we want to create larger >> libraries that are the combination of various subsets of the smaller ones. >> In automake these are called convenience libraries and I suspect they may >> have been the reason for CMake OBJECT in the first place. Given the >> current >> behaviour we have to build all the projects twice once in SHARED library >> form on once in OBJECT library form. If TARGET_OBJECTS was populated for >> SHARED libraries we would not need to build everything twice as we could >> build everything SHARED but still use TARGET_OBJECTS to build combination >> convenience libraries. >> >> Of course maybe there's already a way to do this without having to >> build twice which I don't know about. > > -- 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
[CMake] Non OBJECT libraries and population of $
Currently you can create an OBJECT library using "add_library( OBJECT ...)" this populates $ which can then later be used using something like "target_sources(name PUBLIC $)". I am wondering if there is some reason that $ can't be populated when you create a shared or static library, for instance using "add_library( SHARED ...)". Looking at the output the VS 2017 generators for "add_library( OBJECT ...)" it seems to actually build a static library anyway. I suspect that all the files are compiled to object files somewhere for both STATIC and SHARED libraries, if so would it not be possible to point $ as these object files? The reason I ask is that we have a a bunch of source code that builds in about 100 projects. These projects have a normal hierarchical dependency tree. However when distributing we want to create larger libraries that are the combination of various subsets of the smaller ones. In automake these are called convenience libraries and I suspect they may have been the reason for CMake OBJECT in the first place. Given the current behaviour we have to build all the projects twice once in SHARED library form on once in OBJECT library form. If TARGET_OBJECTS was populated for SHARED libraries we would not need to build everything twice as we could build everything SHARED but still use TARGET_OBJECTS to build combination convenience libraries. Of course maybe there's already a way to do this without having to build twice which I don't know about. -- 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
[CMake] Visual Studio 2010 default property sheets
Sorry if this a re-post had mail issue. I'm not sure if this has been discussed much within the CMake developer community but I wanted to give some thoughts on the use of Visual Sudio property sheets and some suggestion for CMake. As far as I know this is only relevant to Visual Studio 10 and hence MSBuild. I am not familiar with older versions of VS. Sorry if this a bit long winded or it falls into the bleeding obvious category. I did look around and couldn't find any discussion like this online. So first an overview of property sheets in VS10/MSBuild skip this if you are in the know. For those not to familiar with property sheets you can consider them to be collections of compiler/linker flags and other build related information. Physically property sheets are just MSBuild XML files which get included into the main Visaul Studio project file, the .vcxproj file, which is also an MSBuild XML file. To a certain degree you can consider one of Visual Studio functions to be a glorified editor of MSBuild XML files. When you create a project in Visual Studio you have to select what type of project it is, for instance a standard DLL, aka shared library, project. When you do this the project file that VS produces will automatically includes certain property sheets that Microsoft supplies with MSBuild. These files can be found in something like C:\Program Files (x86)\MSBuild\Microsoft.Cpp/v4.0 and have names like Microsoft.Cl.Common.props. The is also a sub directory called Platforms which contains directories like Win32 and x64. These correspond directly to the Platform you see in VS. These directories contain further MSBuild predefined platform specific property sheets like Microsoft.Cpp.Win32.props Property sheets can be inherited what this means is that a property sheet can inherit a set of compiler flags from a parent sheet and can override or extend them if it wants to. This is the key to the usefulness of property sheets. If you look in the Property Manager screen in VS of a standard DLL project you should see something like the following property sheets being inherited for a 32 bit windows build Microsoft.Cpp.Win32.user Windows Dynamic Link Library Multi-byte Character Support Core Windows Libraries Sheets higher up inherit and can override sheets lower down the list. The bottom three correspond to MSBuild supplied property sheets in the MSBuild install directories mentioned earlier. Sadly I haven't found a way in the VS GUI of finding out the actual file name and path of the property sheet but you can normally guess it. The Microsoft.Cpp.Win32.user property sheet which is normally somewhere like AppData\Local\Microsoft\MSBuild\v4.0 in your user id allows you to store user specific build overrides which is generally a bad idea. When you right click on a project in VS solution explorer ( or other equivalent method ) you can look at the properties of that project, including all the compiler/linker flags. Items that are in bold font are defined directly in the property sheet you are looking at while non bold indicates a value that has been inherited. For some compiler flags like the include path it makes sense to inherit the value from your parent property sheet and extend it. In this case you'll see something like %(AdditionIncludeDirectories) in the value which is a macro value representing the value of this field inherited from the parent sheet. A very key portion of the property sheet you can see in VS GUI is the General page under Configuration Properties. At the bottom of this screen is a section called Project Defaults which looks something like Configuration Type Dynamic Library (.dll) Use of MFC Use Standard Windows Libraries Use of ATL Not using ATL Character Set Use Multi Byte Character Set Common Language Runtime Support No Common Language Runtime Support Whole Program Optimization No Whole Program Optimization The above are not really compiler flags directly but define which MSBuild supplied property sheets to inherit. In other words they effect compiler flags used in your build by changing what property sheets you inherit from. So if you change the Character set from multi byte to Unicode you will see in the property manager that you now inherit from a sheet called Unicode Support rather than Multi-byte Character set. This may change many compiler/linker flags/defines etc... Note the situation is a little more complicated as you can define certain MSBuild XML elements before you inherit the MSBuild supplied property sheets which influence what flags they set. A good exmple of this is the UseDebugLibrariestrueUseDebugLibraries which amongst many other things makes the build process link to the debug versions MDd of the MS runtime libraries rather than the optimized/release ones. End of overview So what was the point of this ramble
[CMake] Visual Studio 10 default property sheets
I'm not sure if this has been discussed much within the CMake developer community but I wanted to give some thoughts on the use of Visual Sudio property sheets and some suggestion for CMake. As far as I know this is only relevant to Visual Studio 10 and hence MSBuild. I am not familiar with older versions of VS. Sorry if this a bit long winded or it falls into the bleeding obvious category. I did look around and couldn't find any discussion like this online. So first an overview of property sheets in VS10/MSBuild skip this if you are in the know. For those not to familiar with property sheets you can consider them to be collections of compiler/linker flags and other build related information. Physically property sheets are just MSBuild XML files which get included into the main Visaul Studio project file, the .vcxproj file, which is also an MSBuild XML file. To a certain degree you can consider one of Visual Studio functions to be a glorified editor of MSBuild XML files. When you create a project in Visual Studio you have to select what type of project it is, for instance a standard DLL, aka shared library, project. When you do this the project file that VS produces will automatically includes certain property sheets that Microsoft supplies with MSBuild. These files can be found in something like C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0 and have names like Microsoft.Cl.Common.props. The is also a sub directory called Platforms which contains directories like Win32 and x64. These correspond directly to the Platform you see in VS. These directories contain further MSBuild predefined platform specific property sheets like Microsoft.Cpp.Win32.props Property sheets can be inherited what this means is that a property sheet can inherit a set of compiler flags from a parent sheet and can override or extend them if it wants to. This is the key to the usefulness of property sheets. If you look in the Property Manager screen in VS of a standard DLL project you should see something like the following property sheets being inherited for a 32 bit windows build Microsoft.Cpp.Win32.user Windows Dynamic Link Library Multi-byte Character Support Core Windows Libraries Sheets higher up inherit and can override sheets lower down the list. The bottom three correspond to MSBuild supplied property sheets in the MSBuild install directories mentioned earlier. Sadly I haven't found a way in the VS GUI of finding out the actual file name and path of the property sheet but you can normally guess it. The Microsoft.Cpp.Win32.user property sheet which is normally somewhere like AppData\Local\Microsoft\MSBuild\v4.0 in your user id allows you to store user specific build overrides which is generally a bad idea. When you right click on a project in VS solution explorer ( or other equivalent method ) you can look at the properties of that project, including all the compiler/linker flags. Items that are in bold font are defined directly in the property sheet you are looking at while non bold indicates a value that has been inherited. For some compiler flags like the include path it makes sense to inherit the value from your parent property sheet and extend it. In this case you'll see something like %(AdditionIncludeDirectories) in the value which is a macro value representing the value of this field inherited from the parent sheet. A very key portion of the property sheet you can see in VS GUI is the General page under Configuration Properties. At the bottom of this screen is a section called Project Defaults which looks something like Configuration TypeDynamic Library (.dll) Use of MFC Use Standard Windows Libraries Use of ATL Not using ATL Character Set Use Multi Byte Character Set Common Language Runtime Support No Common Language Runtime Support Whole Program Optimization No Whole Program Optimization The above are not really compiler flags directly but define which MSBuild supplied property sheets to inherit. In other words they effect compiler flags used in your build by changing what property sheets you inherit from. So if you change the Character set from multi byte to Unicode you will see in the property manager that you now inherit from a sheet called Unicode Support rather than Multi-byte Character set. This may change many compiler/linker flags/defines etc... Note the situation is a little more complicated as you can define certain MSBuild XML elements before you inherit the MSBuild supplied property sheets which influence what flags they set. A good exmple of this is the UseDebugLibrariestrueUseDebugLibraries which amongst many other things makes the build process link to the debug versions MDd of the MS runtime libraries rather than the optimized/release ones. End of overview So what was the point of this ramble through property sheets. My assertion is that
[CMake] Managed C++/CLI, default build flags and configurations
Hi,
I have a number of projects which contain mostly sub-directories with
standard C++. I currently build all this stuff on Linux and Windows
and everything is great. However I have a couple of directories in
these projects which contain managed C++/CLI code so that I can expose
the unmanaged C++ functionality to the rest of the Microsoft universe,
obviously these directories build only on Windows. Currently I include
the following snippet of CMake code, which I found on another post, to
fix the compiler flags to enable the managed build
# Managed C++ set up
set_target_properties(${TargetName} PROPERTIES COMPILE_FLAGS /clr)
if(CMAKE_CXX_FLAGS_DEBUG MATCHES /RTC1)
string(REPLACE /RTC1 CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG})
endif()
if(CMAKE_CXX_FLAGS MATCHES /EHsc)
string(REPLACE /EHsc CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
endif()
My question is whether there is a better way to do this as the above
seems a bit brittle and manual. For instance is it possible to define
a new build configuration and somehow signal in the CMake input file
that this directory should use it. In general what I want to be able
to do is to indicate that a different set of default compile flags
should be used for a given directory rather than the default.
I am happy to spend time working on this and sharing any results but
would appreciate any pointers from the CMake experts before I start so
I don't go off wasting my time.
David
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: Bug fix requests for the *next* release of CMake...
I would second this, I have been manually removing the CMAKE_INTDIR by hand, I'm not sure why it's even there for C++ compiles. I prefer my compile lines as clean and simple as possible and I don't use this compile line define anywhere. If I want a compile line define to indicate what CMAKE_INT does I can add it myself very easily but I don't see any easy way to make it not added of to remove it. Which segways me into 1) Does the patch you mention remove all the C++ defines from the midl command line? To my mind the defines you would want for IDL and C++ are pretty orthoginal so why force one on the other 2) Is there a general standard way to change the default flags you get for the compile line. As a for instance on a VS 10 debug build you get -RTC1 added which causes, amongst other things run time checking of undefined variable. This is toxic at run time for Boost which uses undefined variables for their types not their values so you get a runtime exception and I'm not man enough to attempt to play in the Boost code base. The only way I managed to get this flag changed, after various failed attempts at regex replacment of CMAKE variable and other Web suggested things, to the less problematic -RTCs was do download the source code replace RTC1 wherever I found it and build my own patched version. This seems a bit extreme. If someone know standard way of changing the default compile line switches for a given project, in other words not not by modifying you standard cmake install, can it be added to the FAQ/Wiki? Thanks On Thu, Nov 11, 2010 at 11:52 PM, Tony Bridges abrid...@rim.com wrote: Hi David, 0008165 - vs2005 midl chokes on CMAKE_INTDIR (also 2008) http://public.kitware.com/Bug/view.php?id=8165 I would love to see a fix for 0008165 in the next version. Each new version we pick up, I have to reapply Robert Lenhardt's patch and rebuild. http://public.kitware.com/Bug/file_download.php?file_id=1887type=bug The change is simple and isolated, from what I can see. Thanks! /t -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of David Cole Sent: Wednesday, November 10, 2010 12:53 PM To: Adam J Richardson Cc: cmake@cmake.org Subject: Re: [CMake] Bug fix requests for the *next* release of CMake... On Fri, Nov 5, 2010 at 6:29 AM, Adam J Richardson fat...@crackmonkey.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, Replies requested. CMake is already pretty awesome from my POV, but since you ask... Replies on this thread should just be a collector for bug numbers. Afraid I don't have a bug number, but I can explain quickly. If you have a particular issue that you think should be fixed for inclusion in 2.8.4, please bring it up now. Could you guys have a chat with the Boost guys and fix the future safety of FindBoost.cmake somehow? Fiddling with ADDITIONAL_VERSIONS is really a pain on a build farm. Oh, and include Mateusz Loskot's FindODBC.cmake in the release? To include a new module in CMake, we need a module maintainer for it, as outlined here: http://www.cmake.org/Wiki/CMake:Module_Maintainers So unless there is a volunteer for FindODBC, it will not be in CMake. Let me know if you or somebody you know wants to be that volunteer. David Thanks, Adam J Richardson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzT3GwACgkQSUH6dLOqvqlyOQCfaC2+BL+jkULzetoh3bduWoHU tmMAniddpSiMW4KpeRjpS0me9C+3RNjm =4TE7 -END PGP SIGNATURE- ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] MIDL and Visual Studio 10 with |CMake 2.8.3
I have a project containing a few MIDL files that has been working
fine using the Visual Studio 9 2008 generator. I have been migrating
the project over to Visual Studio 2010 which includes using the cmake
Visual Studio 10 generator. However the resultant Visual Studio 2010
files do not seems to recognize the idl files, they appear as simple
text files and consequently no call is made to the MIDL compiler. Is
this expected, in the sense of there being no support, or is there
some change I need to make to the input CMakeList.txt files in this
new version. Note I am using CMake 2.8.3 on a Window 7 box.
An test case, fairly minimal CMakeList.txt file I was trying is as
follows. It builds client and server side library for other bits of
the program to link to ( I would be interested if anyone has helpful
criticisms of my probably woeful CMake style/ability )
add_definitions(-DSECURITY_WIN32)
include_directories(
${CMAKE_CURRENT_BINARY_DIR}/rpc_server.dir/${CMAKE_CFG_INTDIR}
${CMAKE_CURRENT_SOURCE_DIR})
set( FileListServer
Server.cpp
Server.h
Test.idl
dlldefines.h)
source_group( FILES ${FileListServer} )
add_library(
rpc_server ${LIBRARY_SHARED_OR_STATIC}
${FileListServer})
target_link_libraries(rpc_server rpcrt4.lib ntdsapi.lib secur32.lib
netapi32.lib)
install(TARGETS rpc_server RUNTIME DESTINATION bin LIBRARY DESTINATION lib)
set( FileListClient
Client.cpp
Client.h
dlldefines.h)
source_group( FILES ${FileListClient} )
add_library(
rpc_client ${LIBRARY_SHARED_OR_STATIC}
${FileListClient})
target_link_libraries(rpc_client rpcrt4.lib ntdsapi.lib secur32.lib
netapi32.lib)
install(TARGETS rpc_client RUNTIME DESTINATION bin LIBRARY DESTINATION lib)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
