--snip--<br>I'm using Boost and I've never hard to work with special defines and<br>
compile flags. That's the power of proper automatic support.<br>--end snip--<br><br>That's the power of Boost. These guys have really figured it out. I too would like to see some of the Boost.Build concepts make their way into CMake. I just noticed this thread and I feel it is very important for the future development of CMake. So I am going to break this down... preface all statements with IMO (which I hope accounts for something after 9yrs of embedded systems development)<br>
<br>-snip-<br>I've only got a single lib dir. Shouldn't all variants have a unique name?<br>-end snip-<br><br>Yes! Yes! Yes! Boost.Build and boost-cmake do this right. Though I have had to patch boost-cmake. Take look at BoostCore.cmake in boost-cmake this should lead you in the right direction. Why is this important? When you fall into the development of embedded systems and need to build realease, profile, debug for multiple targets the name mangling is a critical need to keep everything strait. I mean imagine for a minute that you have three embedded targets of different architectures, 486, 586, and PentiumM and you need to build your software for each. Boost-Build also allowed us to build ALL VARIANTS of ALL TARGETS with 1 command line. boost-cmake is the closest attempt at this in CMake which will generate projects for Release and Debug and show both in the VS project regardless of which variant you are building for.<br>
<br>-snip-<br>Shouldn't this be done automatically?<br>-end snip--<br><br>Yes! Absolutely! CMake Should! <br><br>-snip-<br>No way. Not all users would want that on all platforms that CMake<br>
supports. Also it is very easy to add a single line to your<br>
CMakeLists.txt file..<br>-end snip-<br><br>Then provided it for those who do and for those who don't allow them to disable/enable the feature. Sooner or later those who don't will be in the boat of those who do. Engeineer CMake for the most common denominator not the least common denominator that way we can get the most out of CMake.<br>
<br>-snip-<br>How will the loader load the correct DLL if they've got the same name?<br>
-end snip-<br><br>Save the asprin and name mangle the dlls as boost does.<br><br>-snip-<br>even Boost's crazy naming schemes can be found _most_ of the time.<br>
-end snip-<br><br>Boost guys have it figured out. This is why I recommended the switch to Boost.Build over GNU Make for embedded system development. I guess you have to be a little "crazy" to redefine the C++ standard.<br>
<br>--snip--<br> So here is what really happens with Visual Studio. When you invoke
CMake you select to build "Shared" libraries and a Win64 application.
These are the basics. Visual Studio will create a subdirectory for
"Debug" and "Release" variants for you. So when you build you get a
shared library with debug symbols placed in the Build/Debug/ directory
and the same for Release (Build/Release). Now. since these are
completely separate directories when you execute your program the
correct libraries will be found. Great. This falls apart if you
"install" your project to a location for other projects to get to. Then
one library will over write the other.<br>--end snip--<br><br>--snip--<br> In a typical CMake workflow one would create another build directory
and rerun CMake again to generate another Visual Studio solution that
would have say a 32 bit Static build in it. This is what CMake kind of
expects. You can abuse this if you want. Take a look at the boost-cmake
project.<br>
--end snip-<br><br>Cmake should expect more from itself. Boost is not abuse! It's the way of the future. boost-cmake is the closest thing to sanity I have seen in CMake projects and is the only one I can tightly integrate with in my projects using add_subdirectory. So they are doing something right. <br>
<br>--snip--<br>
Since I use Qt for my apps and they have a set way of doing things
and since CMake can find those libraries in both Debug and Release
variants then I modeled my own projects so they produce the same type of
naming scheme as Qt. This allows me to install both a Debug and Release
version into a location where other projects can find them, say
C:\Developer\i386\MyProject or C:\Developer\x64\MyProject.<br>
--end snip--<br><br>I only whish CMake had a model. Not just a loose collection of build functions so I can create my own model, which is fine for wheel reinvention or if I need to get CMake to do something specific. <br>
<br>--snip--<br>
If you want to go even further and decorate your library names like
boost does then go ahead and write the CMake code (or grab it from the
Boost-cmake project).<br>--end snip-<br><br>Yes grab it from BoostCore.cmake and post it to CMake as a feature
request... Please! <br><br>--snip--<br> CMake only needs to do what the other platforms do
which is NOT decorate the library names. VS does not do this by
default. Xcode does not. Eclipse does not. Makefiles do not (unless you
write it to). SO that is why CMake does not do it.<br>
--end snip-<br><br>Lets not confuse editor/debugger tools with how the build tool should work. If we are all going to rely on what VS is capable of then we are doomed as programmers. I might as well throw in my debugger and become a Shrimp Boat Captain. Eclipse dose not? Eclipse does not with Makefiles... Eclipse DOES with bjam which worked great for me for 3 years. VS not so much. CMake needs to do what the programmer needs it to do not what some crappy platform/code editor tool expects. Even in VS I am forcing CMake and VS to do my bidding using my wierding ways. I also use Eclipse+VS+CMake. As for "Makefiles do not" we started out writing them to then just switched to a build system that did it by default... Boost.Build bjam!<br>
<br>--snip--<br>
You _can_ very easily do this if you want. The code is out there in
the wild in the form of macros that can be invoked from CMake that will
set all of this up for you. You just have to look for it (or ask the
right person... )<br>--end snip--<br><br>Is there a secret handshake too? :-) I just wish this was a part of CMake with a couple of examples for thoes of us "crazy" enough to want this feature.<br><br>I think what we will find that if this is not implemented as part of some standard of CMake use then third party library creators will not implement it and when it is needed by the programmer who does they will be stuck rewriting the third party developer build system. Case in point:<br>
<br>--snip--<br>Yes, it was done already (For some of them) which is what I started
with. But what you find is that the CMake files that someone wrote are
kinda "tweaked" for their project and don't really work for yours so you
end up forking the project, pushing it into your own source repo and
fixing the problems. Exacerbating this issue is that some upstream
developers want NOTHING to do with CMake and so will NOT add the CMake
files to their projects. So you are stuck keeping your own pathced
versions. Is this what is optimal nope but this is what we get.<br>
I thought there was some sort of project setup which aimed to keep a
separate patch for some of the major opensource projects where the
original source would be downloaded then patched with the cmake files
thus creating a "CMakeified" version of the library. Can not remember
what the name of the project was. I think it was hosted at google code.<br>--end snip--<br><br>-snip-<br>Why is this abuse?<br>
Because it circumvents CMakes generally accepted practice of a single
type of configuration per build directory. I guess "abuse" is subject to
each different person.<br>-end snip-<br><br>It's not abuse. I wonder if there was a statictical sampling for "generally accepted practice". I sure don't agree with it. I must have been in the "minority" district with the conveniently malfunctioning voting machine when the poll was taken. It's that frigging Electoral College thing again isn't it! :-)<br>
<br>I think CMake could use:<br><br>1) standard name mangling which was flexible enough to be turned on and off and implemented by Third Party Package developers perhaps with out them even realizing it<br>2) better support for integrating Third Party Packages using add_subdirectory. For what I mean google "Build only what you need in third party libs" or see <a href="http://www.cmake.org/pipermail/cmake/2010-January/034908.html">http://www.cmake.org/pipermail/cmake/2010-January/034908.html</a><br>
3) elimination of the use of GLOBAL CMAKE_C_FLAGS and friends<br>4) Addition of projects (I don't know what the current "project" concept in CMake is useful for... yes I know for specifying the language/build tool.. but it stops there) and project inheritacne vs subdirectory inheritace of build settings. I am currently trying to flush this out and will post my successes/failures.<br>
5) An "Easy Button"... well I can ask can't I? :-)<br><br>I have currently gone by the way of boost in calling macros/functions (which I am currently refining) for generating my projects such as:<br><br>-snip CMakeLists.txt-<br>
add_gpu_matlab_mex_library( <br> gpuPMatrixRecon<br> CPP_SOURCES <br> gpuPMatrixRecon.cpp <br> CUDADeviceProperties.cpp<br># CU_SOURCES gpuPMatrixRecon.cu<br> DEFINES CUDADeviceProperties_DLLExport=yes GPU_RECON=yes<br>
MEX_ENTRY_FUNCTION yes<br>)<br>-end snip--<br><br><br>-snip add_gpu_matlab_mex_library.cmake -<br>#macro( add_gpu_matlab_mex_library LIB_NAME )<br>function( add_gpu_matlab_mex_library LIB_NAME )<br><br> PARSE_CMAKE_ARGUMENTS(ARG<br>
"SRCDIRS;INCLUDE_DIRS;CPP_SOURCES;CU_SOURCES;LINK_LIBS;DEFINES;DLL_EXPORT_FUNCTIONS;MEX_ENTRY_FUNCTION;VTK_ENABLED" ""<br> ${ARGN}<br> )<br><br> message("Generating mex/cuda library ${LIB_NAME}" )<br>
message("\tARG_SRCDIRS = ${ARG_SRCDIRS}" )<br> message("\tARG_CPP_SOURCES = ${ARG_CPP_SOURCES}" )<br> message("\tARG_CU_SOURCES = ${ARG_CU_SOURCES}" )<br> message("\tARG_LINK_LIBS= ${ARG_LINK_LIBS}")<br>
message("\tARG_MEX_ENTRY_FUNCTION= ${ARG_MEX_ENTRY_FUNCTION}")<br> <br> cmake_minimum_required(VERSION 2.8)<br><br># SET( MATLAB_CUDA_MEX_NAME ${LIB_NAME} )<br><br> SET( MATLAB_CUDA_FILES ${ARG_CU_SOURCES} ${ARG_CPP_SOURCES} )<br>
<br> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS 1)<br><br><br> INCLUDE_DIRECTORIES( <br> ./<br> )<br><br> if(DEFINED ARG_INCLUDE_DIRS)<br> foreach( INCLUDE_DIR ${ARG_INCLUDE_DIRS} )<br>
INCLUDE_DIRECTORIES( ${INCLUDE_DIR} )<br> endforeach()<br> endif()<br><br><br> LINK_DIRECTORIES(<br> ${MATLAB_LIBRARIES}<br> ${MATLAB_MEX_LIBRARY}<br> ${MATLAB_MX_LIBRARY}<br>
${MATLAB_ENG_LIBRARY}<br> "${TOP}/build/dvip4-Win64/lib/Debug"<br> )<br><br> if(DEFINED ARG_VTK_ENABLED )<br> message( "\tEnabling VTK" )<br><br> LINK_DIRECTORIES( <br>
${CMAKE_INSTALL_PREFIX}/lib <br> ${CMAKE_INSTALL_PREFIX}/lib/vtk-${VTK_LIB_VERSION_INCLUDE}<br> ${CMAKE_INSTALL_PREFIX}/lib/VTKEdge<br> )<br><br> SET( <br> VTK_LIBS <br>
vtkCommon<br> vtkDICOMParser<br> vtkFiltering<br> vtkGraphics<br> vtkImaging<br> vtkIO<br> vtkRendering<br> vtkVolumeRendering<br> )<br>
<br> SET( VTKEDGE_LIBS<br> vtkKWECommon<br> vtkKWEVolumeRendering<br> ) <br> endif()<br> <br> SET( MATLAB_LINK_LIBS<br> libmx<br> libmex<br> libmat<br>
)<br><br><br><br> SET( ${CUDA_LIBRARIES}<br> cudart<br> cuda<br> cublas<br> cublasemu<br> )<br><br><br> foreach( DEFINE_STR ${ARG_DEFINES} )<br> message("\tDEFINE_STR = ${DEFINE_STR}" )<br>
add_definitions( -D${DEFINE_STR} )<br> endforeach()<br><br><br> if(DEFINED ARG_CU_SOURCES )<br> message("\tARG_CU_SOURCES is defined as = ${ARG_CU_SOURCES}" )<br> CUDA_ADD_LIBRARY( ${LIB_NAME} SHARED ${MATLAB_CUDA_FILES} )<br>
else()<br> message("\tARG_CU_SOURCES is not defined" )<br> message("\tdefining library ${LIB_NAME} with sources ${ARG_CPP_SOURCES}")<br> ADD_LIBRARY( ${LIB_NAME} SHARED ${ARG_CPP_SOURCES} )<br>
endif()<br><br> TARGET_LINK_LIBRARIES( ${LIB_NAME}<br> ${MATLAB_LINK_LIBS}<br> ${CUDA_LIBRARIES}<br> ${ARG_LINK_LIBS}<br> )<br><br> if(DEFINED ARG_VTK_ENABLED )<br> TARGET_LINK_LIBRARIES( ${LIB_NAME}<br>
${VTK_LIBS}<br> ${VTKEDGE_LIBS}<br> )<br> endif()<br> <br> <br> if(DEFINED ARG_MEX_ENTRY_FUNCTION)<br> message("\tExporting MEX entry function" )<br> SET_TARGET_PROPERTIES( ${LIB_NAME} PROPERTIES<br>
SUFFIX .mexw64<br> LINKER_LANGUAGE CXX <br> LINK_FLAGS /export:mexFunction<br> )<br> else()<br> message("\tNot exporting MEX entry function" )<br> endif()<br><br>
<br> if(DEFINED ARG_DLL_EXPORT_FUNCTIONS )<br> message("\tExporting functions ${ARG_DLL_EXPORT_FUNCTIONS}" )<br> foreach( FUNCTION_NAME ${ARG_DLL_EXPORT_FUNCTIONS} )<br> message("\t\t Exporting ${FUNCTION_NAME}" )<br>
SET_TARGET_PROPERTIES( ${LIB_NAME} PROPERTIES<br> LINK_FLAGS /export:${FUNCTION_NAME}<br> )<br> endforeach()<br> else()<br> endif()<br> <br> INSTALL( TARGETS ${LIB_NAME} DESTINATION ${CMAKE_CURRENT_SOURCE_DIR} )<br>
<br> INSTALL( TARGETS ${SQUARE_ME_TEST_APP}<br> DESTINATION ${CMAKE_CURRENT_SOURCE_DIR}<br> )<br><br><br><br><br>#endmacro()<br>endfunction()<br><br>--end snip--<br><br>As you can see it is a work in progress as I have not added the LINK_LIBS feature for the vtk goop. Anyway I do this due to the verbosity of the CMake Syntax to preform meaningful work. I started out using the simpletons approach of having verbose CMakeLists.txt files for each lib.. Then I "got smart" or dumber to the point I think I am smart... not sure which.<br>
<br>I am working to add concept of Project Inheritance to these macros.<br><br>What makes this possible is PARSE arguments which is strangely not apart of CMake, which I found in boost and also here <a href="http://www.cmake.org/Wiki/CMakeMacroParseArguments">http://www.cmake.org/Wiki/CMakeMacroParseArguments</a>. Talk about wheel reinvention... you know on the topic I have this concept for this Octagonal wheel to increases fuel efficiency... you get the idea.<br>
<br><br>