Re: [CMake] Question about install()
On Dec 7, 2008, at 1:20 AM, Robert Dailey wrote: Hi, I have a couple of DLL files I want to copy to my executable's directory as a post-build event in the CMake-generated visual studio project files. I know I have to use install() for this, however I'm not sure how I can tell install() to copy these DLL files to the directory containing the compiled EXE file. I can't seem to find a CMAKE variable that represents the containing directory of this EXE file. Note I'm building out of source. Thanks. There are a few variables that control where the final executables, libraries and archives are created. CMAKE_RUNTIME_OUTPUT_DIRECTORY CMAKE_LIBRARY_OUTPUT_DIRECTORY CMAKE_ARCHIVE_OUTPUT_DIRECTORY • RUNTIME_OUTPUT_DIRECTORY: Output directory in which to build RUNTIME target files. This property specifies the directory into which runtime target files should be built. There are three kinds of target files that may be built: archive, library, and runtime. Executables are always treated as runtime targets. Static libraries are always treated as archive targets. Module libraries are always treated as library targets. For non-DLL platforms shared libraries are treated as library targets. For DLL platforms the DLL part of a shared library is treated as a runtime target and the corresponding import library is treated as an archive target. All Windows-based systems including Cygwin are DLL platforms. This property is initialized by the value of the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY if it is set when a target is created So you can do something like: SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all executables" ) SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all dynamic Libraries" ) SET (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all static Libraries" ) BEFORE any "add_library" or "add_executable" is called. That way all your built products will be created in the same directory when being built. Now, that assumes that your "couple of dlls" were built by your project. If they were NOT built by your project (say for example, Qt libraries) then you will want to try something a bit different. cmake -E can be used to copy files. You may want to look at the add_custom_command(TARGET ${yourExeTarget} POST_BUILD COMMAND ${CMAKE_COMMAND} -E {path to source dll} {path to dest} . ) This will probably copy the files _every_ time the target is built although I am not sure on that point. You can look up the help for add_custom_command and see if this will help you out. _ Mike Jackson [EMAIL PROTECTED] www.bluequartz.net ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Sun, Dec 7, 2008 at 7:01 AM, Michael Jackson <[EMAIL PROTECTED] > wrote: > There are a few variables that control where the final executables, > libraries and archives are created. > > CMAKE_RUNTIME_OUTPUT_DIRECTORY > CMAKE_LIBRARY_OUTPUT_DIRECTORY > CMAKE_ARCHIVE_OUTPUT_DIRECTORY > >• RUNTIME_OUTPUT_DIRECTORY: Output directory in which to build > RUNTIME target files. > This property specifies the directory into which runtime target files > should be built. There are three kinds of target files that may be built: > archive, library, and runtime. Executables are always treated as runtime > targets. Static libraries are always treated as archive targets. Module > libraries are always treated as library targets. For non-DLL platforms > shared libraries are treated as library targets. For DLL platforms the DLL > part of a shared library is treated as a runtime target and the > corresponding import library is treated as an archive target. All > Windows-based systems including Cygwin are DLL platforms. This property is > initialized by the value of the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY if > it is set when a target is created > > So you can do something like: > > SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH > "Single Directory for all executables" > ) > SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH > "Single Directory for all dynamic Libraries" > ) > SET (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH > "Single Directory for all static Libraries" > ) > > BEFORE any "add_library" or "add_executable" is called. That way all your > built products will be created in the same directory when being built. Now, > that assumes that your "couple of dlls" were built by your project. If they > were NOT built by your project (say for example, Qt libraries) then you will > want to try something a bit different. > > cmake -E can be used to copy files. > > You may want to look at the add_custom_command(TARGET ${yourExeTarget} >POST_BUILD >COMMAND ${CMAKE_COMMAND} -E > {path to source dll} {path to dest} >. ) > > This will probably copy the files _every_ time the target is built although > I am not sure on that point. > > You can look up the help for add_custom_command and see if this will help > you out. I tried the following, but it didn't print anything. Are you sure these variables even exist? message( "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}" ) message( "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}" ) message( "${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}" ) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Dec 7, 2008, at 1:02 PM, Robert Dailey wrote: On Sun, Dec 7, 2008 at 7:01 AM, Michael Jackson <[EMAIL PROTECTED] > wrote: There are a few variables that control where the final executables, libraries and archives are created. CMAKE_RUNTIME_OUTPUT_DIRECTORY CMAKE_LIBRARY_OUTPUT_DIRECTORY CMAKE_ARCHIVE_OUTPUT_DIRECTORY • RUNTIME_OUTPUT_DIRECTORY: Output directory in which to build RUNTIME target files. This property specifies the directory into which runtime target files should be built. There are three kinds of target files that may be built: archive, library, and runtime. Executables are always treated as runtime targets. Static libraries are always treated as archive targets. Module libraries are always treated as library targets. For non-DLL platforms shared libraries are treated as library targets. For DLL platforms the DLL part of a shared library is treated as a runtime target and the corresponding import library is treated as an archive target. All Windows-based systems including Cygwin are DLL platforms. This property is initialized by the value of the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY if it is set when a target is created So you can do something like: SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all executables" ) SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all dynamic Libraries" ) SET (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all static Libraries" ) BEFORE any "add_library" or "add_executable" is called. That way all your built products will be created in the same directory when being built. Now, that assumes that your "couple of dlls" were built by your project. If they were NOT built by your project (say for example, Qt libraries) then you will want to try something a bit different. cmake -E can be used to copy files. You may want to look at the add_custom_command(TARGET ${yourExeTarget} POST_BUILD COMMAND $ {CMAKE_COMMAND} -E {path to source dll} {path to dest} . ) This will probably copy the files _every_ time the target is built although I am not sure on that point. You can look up the help for add_custom_command and see if this will help you out. I tried the following, but it didn't print anything. Are you sure these variables even exist? message( "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}" ) message( "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}" ) message( "${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}" ) # project(test) SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all executables" ) message(STATUS "CMAKE_RUNTIME_OUTPUT_DIRECTORY: $ {CMAKE_RUNTIME_OUTPUT_DIRECTORY}") Then I ran cmake 2.6.2 on that CMakeLists.txt file and I get the following: -- CMAKE_RUNTIME_OUTPUT_DIRECTORY: /Users/mjackson/Desktop/test/Build/ Bin -- Configuring done -- Generating done -- Build files have been written to: /Users/mjackson/Desktop/test/Build Odd yours does not print anything out. Can you run the above short CMakeLists.txt file and see what gets output? Also is this what you are looking for or did you want to copy external libraries into the build directory? _ Mike Jackson [EMAIL PROTECTED] BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Sun, Dec 7, 2008 at 1:05 PM, Michael Jackson <[EMAIL PROTECTED] > wrote: > # > project(test) > SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin > CACHE PATH > "Single Directory for all executables" > ) > message(STATUS "CMAKE_RUNTIME_OUTPUT_DIRECTORY: > ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}") > > Then I ran cmake 2.6.2 on that CMakeLists.txt file and I get the following: > -- CMAKE_RUNTIME_OUTPUT_DIRECTORY: /Users/mjackson/Desktop/test/Build/Bin > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/mjackson/Desktop/test/Build > > Odd yours does not print anything out. Can you run the above short > CMakeLists.txt file and see what gets output? Also is this what you are > looking for or did you want to copy external libraries into the build > directory? Of course yours will print something, as you're clearly setting the variable right above your message() call. I'm printing it without setting it first, as I do not want to change the output location of my binaries. The default should be ./Debug or ./Release, depending on the configuration. Yours looks like it will place both release and debug executables in the same directory, which I do not want. How do I get the default output location for my binaries? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Dec 7, 2008, at 2:42 PM, Robert Dailey wrote: On Sun, Dec 7, 2008 at 1:05 PM, Michael Jackson <[EMAIL PROTECTED] > wrote: # project(test) SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/Bin CACHE PATH "Single Directory for all executables" ) message(STATUS "CMAKE_RUNTIME_OUTPUT_DIRECTORY: $ {CMAKE_RUNTIME_OUTPUT_DIRECTORY}") Then I ran cmake 2.6.2 on that CMakeLists.txt file and I get the following: -- CMAKE_RUNTIME_OUTPUT_DIRECTORY: /Users/mjackson/Desktop/test/ Build/Bin -- Configuring done -- Generating done -- Build files have been written to: /Users/mjackson/Desktop/test/ Build Odd yours does not print anything out. Can you run the above short CMakeLists.txt file and see what gets output? Also is this what you are looking for or did you want to copy external libraries into the build directory? Of course yours will print something, as you're clearly setting the variable right above your message() call. I'm printing it without setting it first, as I do not want to change the output location of my binaries. The default should be ./Debug or ./Release, depending on the configuration. Yours looks like it will place both release and debug executables in the same directory, which I do not want. How do I get the default output location for my binaries? Mine was run on OS X using a Makefile. If I use Xcode I would probably get something else. I use that exact same call on windows and VS 7,8,9 will all still use the "Debug" or "Release" directories based on the configuration. _ Mike Jackson [EMAIL PROTECTED] BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Sun, Dec 7, 2008 at 3:39 PM, Michael Jackson <[EMAIL PROTECTED] > wrote: > Mine was run on OS X using a Makefile. If I use Xcode I would probably get > something else. I use that exact same call on windows and VS 7,8,9 will all > still use the "Debug" or "Release" directories based on the configuration. Thanks for clarifying. Everything works now, however this doesn't really solve my problem. See, I need to copy shared library files over differently depending on my configuration and also depending on my platform. On Linux the library names will have different suffix/prefix. This becomes even harder when I have to consider debug vs release, since the libraries are also different between configurations as well. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Robert Dailey schrieb: > On Sun, Dec 7, 2008 at 3:39 PM, Michael Jackson <[EMAIL PROTECTED] >> wrote: > >> Mine was run on OS X using a Makefile. If I use Xcode I would probably get >> something else. I use that exact same call on windows and VS 7,8,9 will all >> still use the "Debug" or "Release" directories based on the configuration. > > > Thanks for clarifying. Everything works now, however this doesn't really > solve my problem. See, I need to copy shared library files over differently > depending on my configuration and also depending on my platform. On Linux > the library names will have different suffix/prefix. This becomes even > harder when I have to consider debug vs release, since the libraries are > also different between configurations as well. So what? Instead of copying the DLLs to the build location of the executable, copy _all_ relevant files to an extra location of your choice. The LOCATION_ property also exists. Why do you even care for the name of the actual files? What purpose does it have to name debug and release libraries differently but no being interchangeable? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Mon, Dec 8, 2008 at 4:13 AM, Hendrik Sattler <[EMAIL PROTECTED]>wrote: > Robert Dailey schrieb: > > Thanks for clarifying. Everything works now, however this doesn't really > > solve my problem. See, I need to copy shared library files over > differently > > depending on my configuration and also depending on my platform. On Linux > > the library names will have different suffix/prefix. This becomes even > > harder when I have to consider debug vs release, since the libraries are > > also different between configurations as well. > > So what? Instead of copying the DLLs to the build location of the > executable, copy _all_ relevant files to an extra location of your choice. This makes absolutely no sense to me. To copy "all relevant files", I have to know their name. To know their name, I need to know the platform and the build configuration, since as I said before the names are different in both cases. > The LOCATION_ property also exists. > > Why do you even care for the name of the actual files? What purpose does > it have to name debug and release libraries differently but no being > interchangeable? I don't think you understand. I have no control over the names of the shared libraries, since I am using third party libraries, such as boost. For example, in debug I need to use boost_filesystem-mt-gd.dll, and in release I use boost_filesystem-mt.dll. On Linux debug & release, the suffix will probably .so instead of .dll. I cannot debug my applications unless the DLL files can be copied to the location of the executable. I think your confusion lies in the fact that I'm copying the DLLs manually. Normally, developers would setup their projects in such a way that it is the responsibility of the person building the source code to go out and download & install third party dependencies as needed. In my case, I am keeping all dependencies with my project along with prebuilt binaries for all platforms I plan to support. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Robert Dailey schrieb: > This makes absolutely no sense to me. To copy "all relevant files", I have > to know their name. To know their name, I need to know the platform and the > build configuration, since as I said before the names are different in both > cases. How do you link against them if you do not know the name? Do you use that special auto-linking feature of MSVC? > I don't think you understand. I have no control over the names of the shared > libraries, since I am using third party libraries, such as boost. Well, it's obvious that boost library naming sucks a lot. I know that you cannot do anything about that. > For > example, in debug I need to use boost_filesystem-mt-gd.dll, and in release I > use boost_filesystem-mt.dll. On Linux debug & release, the suffix will > probably .so instead of .dll. I cannot debug my applications unless the DLL > files can be copied to the location of the executable. Again, how do you link against those libraries? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Mon, Dec 8, 2008 at 10:49 AM, Hendrik Sattler <[EMAIL PROTECTED]>wrote: > How do you link against them if you do not know the name? Do you use > that special auto-linking feature of MSVC? You specify them as library dependencies on the command line. For the import libraries, I simply use target_link_libraries() in CMake. Well, it's obvious that boost library naming sucks a lot. I know that > you cannot do anything about that. This has nothing to do with boost. This is a very common way of labeling import libraries and their corresponding shared libraries. A typical approach is this: library_d.lib <-- Debug library library.lib <-- Release library I don't see any issue with this. This is required in order to tell them apart so that one may link against the appropriate library. Of course I would not distribute the debug versions, which I think is where you're confused. When I distribute my application the user is only responsible for ensuring they have the release versions of those libraries. Again, how do you link against those libraries? See my answer to your first question. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Dec 8, 2008, at 11:49 AM, Hendrik Sattler wrote: Robert Dailey schrieb: This makes absolutely no sense to me. To copy "all relevant files", I have to know their name. To know their name, I need to know the platform and the build configuration, since as I said before the names are different in both cases. How do you link against them if you do not know the name? Do you use that special auto-linking feature of MSVC? I don't think you understand. I have no control over the names of the shared libraries, since I am using third party libraries, such as boost. Well, it's obvious that boost library naming sucks a lot. I know that you cannot do anything about that. For example, in debug I need to use boost_filesystem-mt-gd.dll, and in release I use boost_filesystem-mt.dll. On Linux debug & release, the suffix will probably .so instead of .dll. I cannot debug my applications unless the DLL files can be copied to the location of the executable. Again, how do you link against those libraries? HS Someone created some cmake code to do just this exact thing earlier this year. I have been trying to hunt it down in the archives but just keep coming up empty. I have some code for an "install" rule. You could put that code in a separate cmake file, configure the file during cmake time, and then run it as a process. Here is some code that I use for an actual "install". MACRO (MXA_INSTALL_SUPPORT_LIBRARY basename) IF (HAVE_${basename}_DLL) IF (WIN32) GET_FILENAME_COMPONENT(${basename}_LIB_DEBUG_NAME ${$ {basename}_LIBRARY_DEBUG} NAME_WE) GET_FILENAME_COMPONENT(${basename}_LIB_RELEASE_NAME ${$ {basename}_LIBRARY_RELEASE} NAME_WE) INSTALL(FILES ${${basename}_BIN_DIR}/${$ {basename}_LIB_DEBUG_NAME}.dll DESTINATION bin CONFIGURATIONS Debug COMPONENT Runtime) INSTALL(FILES ${${basename}_BIN_DIR}/${$ {basename}_LIB_RELEASE_NAME}.dll DESTINATION bin CONFIGURATIONS Release COMPONENT Runtime) ENDIF (WIN32) ENDIF (HAVE_${basename}_DLL) ENDMACRO(MXA_INSTALL_SUPPORT_LIBRARY basename) #-- Install the support libraries if needed IF ( MXA_USE_HDF5 ) MXA_INSTALL_SUPPORT_LIBRARY(HDF5) ENDIF ( MXA_USE_HDF5 ) This assumes that the library you are trying to copy has CMake variables of the form ${basename}_LIB_DEBUG_NAME which boost does. For instance in my project that I use boost, I have the some boost variables of the type: Boost_FILESYSTEM_LIBRARY_DEBUG Boost_FILESYSTEM_LIBRARY_RELEASE Those variables will hold the correct name for each platform that you are compiling on. You could try replacing the INSTALL(.. ) command with some commands to copy the files. _ Mike Jackson [EMAIL PROTECTED] BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Mon, Dec 8, 2008 at 11:09 AM, Michael Jackson < [EMAIL PROTECTED]> wrote: > Someone created some cmake code to do just this exact thing earlier this > year. I have been trying to hunt it down in the archives but just keep > coming up empty. I have some code for an "install" rule. You could put that > code in a separate cmake file, configure the file during cmake time, and > then run it as a process. > > Here is some code that I use for an actual "install". > > > This assumes that the library you are trying to copy has CMake variables of > the form ${basename}_LIB_DEBUG_NAME which boost does. > > For instance in my project that I use boost, I have the some boost > variables of the type: > > Boost_FILESYSTEM_LIBRARY_DEBUG > Boost_FILESYSTEM_LIBRARY_RELEASE > > Those variables will hold the correct name for each platform that you are > compiling on. You could try replacing the INSTALL(.. ) command with some > commands to copy the files. Thanks for the code snippet Michael. It just occurred to me that creating a python script to do the copying might be the best approach. However, I still need a way in CMake to add_custom_command() to a specific configuration, such as debug or release. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Michael, Is there a way to call add_custom_command() on a specific configuration for a specific target? If I can do this then I can use CMAKE to copy the files appropriately and your method would work perfectly. Thanks for your tme. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 11:05 AM, Robert Dailey <[EMAIL PROTECTED]> wrote: > Michael, > > Is there a way to call add_custom_command() on a specific configuration for > a specific target? If I can do this then I can use CMAKE to copy the files > appropriately and your method would work perfectly. > > Thanks for your tme. > After much research, I've found out that CMake cannot provide a custom command (Post build event) to a specific configuration in the case where CMake is used to generate a multi-configuration target, such as a visual studio project. This is a HUGE problem for me. Are there any work-arounds for this issue? Does this issue plan to be addressed in a future release (Hopefully soon)? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Robert Dailey wrote: After much research, I've found out that CMake cannot provide a custom command (Post build event) to a specific configuration in the case where CMake is used to generate a multi-configuration target, such as a visual studio project. This is a HUGE problem for me. Are there any work-arounds for this issue? Does this issue plan to be addressed in a future release (Hopefully soon)? Exactly what are you trying to copy? I might be able to figure out a workaround if I had a better idea of what you were doing. (please keep the example small... :) ) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 4:25 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote: > Robert Dailey wrote: > > >> After much research, I've found out that CMake cannot provide a custom >> command (Post build event) to a specific configuration in the case where >> CMake is used to generate a multi-configuration target, such as a visual >> studio project. This is a HUGE problem for me. Are there any work-arounds >> for this issue? Does this issue plan to be addressed in a future release >> (Hopefully soon)? >> >> > Exactly what are you trying to copy? I might be able to figure out a > workaround if I had a better idea of what you were doing. > > (please keep the example small... :) ) Sure. Sorry for the lack of details. I have a directory that contains DLL files that I need to copy to the directory at which my executable is built. However, the DLL files that I copy over are different depending on the configuration that was used to build the executable. For example, if I've built my executable using the DEBUG configuration, I need to copy over DLL files named foo_d.dll, bar_d.dll. If RELEASE was used to build the executable, then I need to copy over foo.dll and bar.dll. Since the debug/release executables are placed in different directories by CMake when they are built, the destination location for the DLLs also changes across configurations as well. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 4:33 PM, Robert Dailey <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 4:25 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote: > >> Robert Dailey wrote: >> >> >>> After much research, I've found out that CMake cannot provide a custom >>> command (Post build event) to a specific configuration in the case where >>> CMake is used to generate a multi-configuration target, such as a visual >>> studio project. This is a HUGE problem for me. Are there any work-arounds >>> for this issue? Does this issue plan to be addressed in a future release >>> (Hopefully soon)? >>> >>> >> Exactly what are you trying to copy? I might be able to figure out a >> workaround if I had a better idea of what you were doing. >> >> (please keep the example small... :) ) > > > Sure. Sorry for the lack of details. > > I have a directory that contains DLL files that I need to copy to the > directory at which my executable is built. However, the DLL files that I > copy over are different depending on the configuration that was used to > build the executable. For example, if I've built my executable using the > DEBUG configuration, I need to copy over DLL files named foo_d.dll, > bar_d.dll. If RELEASE was used to build the executable, then I need to copy > over foo.dll and bar.dll. Since the debug/release executables are placed in > different directories by CMake when they are built, the destination location > for the DLLs also changes across configurations as well. > I actually did a little thinking and I came up with this: add_custom_command( TARGET ${component_project_name} POST_BUILD COMMAND "depends.py" ARGS "$(ConfigurationName)" ) Of course this only works for visual studio projects, but it does accomplish what I want. The only downside is that I have to put the DLL copy logic in the python script instead of keeping it centralized within CMake. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
2008/12/9 Robert Dailey <[EMAIL PROTECTED]>: > On Tue, Dec 9, 2008 at 11:05 AM, Robert Dailey <[EMAIL PROTECTED]> wrote: >> >> Michael, >> >> Is there a way to call add_custom_command() on a specific configuration >> for a specific target? If I can do this then I can use CMAKE to copy the >> files appropriately and your method would work perfectly. >> >> Thanks for your tme. > > After much research, I've found out that CMake cannot provide a custom > command (Post build event) to a specific configuration in the case where > CMake is used to generate a multi-configuration target, such as a visual > studio project. This is a HUGE problem for me. Are there any work-arounds > for this issue? Does this issue plan to be addressed in a future release > (Hopefully soon)? > I wonder if you could use the "ctest --build-and-test" tool, telling it to configure (run cmake on) some custom little CMakeLists.txt-file that could perform the copying. The "ctest --build-and-test" tool can be given the "--build-config-sample" flag, that helps figuring out whether it is a Debug or Release build currently going on. ctest can thusly set the CMAKE_BUILD_TYPE variable when invoking cmake on that custom CMakeLists.txt-file, so that the latter could perform the copying based on that variable. I'm not sure that I understand your problem correctly (and it's in the middle of the night here) so I will not explain more now ... but take a look at the following example and see if it is possible to understand what it does .. (Note that it needs to be adapted for the case where CMAKE_BUILD_TYPE is set as well in order to be generic, but that is easy) Best regards Hugo Heden Stockholm, Sweden CMAKE_MINIMUM_REQUIRED(VERSION 2.6) PROJECT(test) # Create some dummy source (on the fly, but that is not necessary) and #make sure it is compiled using a subdirectory with a CMakeLists.txt. #The "ctest --build-and-test" (below) will later use the directory in which #the executable ends up to figure out what build type this is. This is what #the --build-config-sample flag is for. FILE( WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy_src/CMakeLists.txt "ADD_EXECUTABLE( dummy dummy.cpp )" ) FILE( WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy_src/dummy.cpp "int main(){}" ) ADD_SUBDIRECTORY( ${CMAKE_CURRENT_BINARY_DIR}/dummy_src/ ${CMAKE_CURRENT_BINARY_DIR}/dummy_build/ ) ADD_CUSTOM_TARGET( some_target ALL DEPENDS dummy COMMAND ${CMAKE_CTEST_COMMAND} --build-and-test ${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command ${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command --build-generator ${CMAKE_GENERATOR} --build-makeprogram ${CMAKE_BUILD_TOOL} --build-noclean --build-config-sample ${CMAKE_CURRENT_BINARY_DIR}/dummy_build/dummy #--build-config ${CMAKE_BUILD_TYPE} ) # Ok, finally, this is the CMakeLists.txt that will be "invoked" by the #ctest-command above.. (here we create it on the fly, but that is # not necessary) FILE( WRITE ${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command/CMakeLists.txt " MESSAGE( STATUS \"Woh - There is a build going on with build type: \${CMAKE_BUILD_TYPE}\") IF( \${CMAKE_BUILD_TYPE} STREQUAL \"Debug\" ) MESSAGE( STATUS \"Woh - here we could copy Debug-dll:s to some Debug destination directory.\") ELSEIF( \${CMAKE_BUILD_TYPE} STREQUAL \"Release\" ) MESSAGE( STATUS \"Woh - here we could copy Release-dll:s to some Release destination directory.\") ENDIF( \${CMAKE_BUILD_TYPE} STREQUAL \"Debug\" ) " ) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Robert Dailey wrote: I actually did a little thinking and I came up with this: add_custom_command( TARGET ${component_project_name} POST_BUILD COMMAND "depends.py" ARGS "$(ConfigurationName)" ) Of course this only works for visual studio projects, but it does accomplish what I want. The only downside is that I have to put the DLL copy logic in the python script instead of keeping it centralized within CMake. You do know about CMAKE_CFG_INTDIR right? It will expand out to the configuration directory name on VS and Xcode, and for makefiles it will be ".". So, you could have:COMMAND "depends.py" ARGS ${CMAKE_CFG_INTDIR}. It will not help with the separate named targets, but it will give you the directory that they are in. If you did not want to use python, you could use cmake -DCONFIG=${CMAKE_CFG_INTDIR} -E myscript.cmake. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tuesday 09 December 2008 22:33:22 Robert Dailey wrote: > I have a directory that contains DLL files that I need to copy to the > directory at which my executable is built. However, the DLL files that I > copy over are different depending on the configuration that was used to > build the executable. For example, if I've built my executable using the > DEBUG configuration, I need to copy over DLL files named foo_d.dll, > bar_d.dll. If RELEASE was used to build the executable, then I need to copy > over foo.dll and bar.dll. Since the debug/release executables are placed in > different directories by CMake when they are built, the destination > location for the DLLs also changes across configurations as well. Are you building these DLLs or are they binaries? If so, why does it need to be post-build and not pre-build? If the latter is acceptable then I've got a solution for you, we've used at my place of work. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Dec 10, 2008, at 6:04 AM, Mike Arthur wrote: On Tuesday 09 December 2008 22:33:22 Robert Dailey wrote: I have a directory that contains DLL files that I need to copy to the directory at which my executable is built. However, the DLL files that I copy over are different depending on the configuration that was used to build the executable. For example, if I've built my executable using the DEBUG configuration, I need to copy over DLL files named foo_d.dll, bar_d.dll. If RELEASE was used to build the executable, then I need to copy over foo.dll and bar.dll. Since the debug/release executables are placed in different directories by CMake when they are built, the destination location for the DLLs also changes across configurations as well. Are you building these DLLs or are they binaries? If so, why does it need to be post-build and not pre-build? If the latter is acceptable then I've got a solution for you, we've used at my place of work. -- Cheers, Mike Arthur http://mikearthur.co.uk/ I'm interested. I always manually drag over the libraries that I need when I develop on Windows. Thanks _ Mike Jackson [EMAIL PROTECTED] BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 9:18 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote: > ... If you did not want to use python, you could use cmake > -DCONFIG=${CMAKE_CFG_INTDIR} -E myscript.cmake... > Make that: cmake -DCONFIG=${CMAKE_CFG_INTDIR} -P myscript.cmake -P for *p*rocess script, not -E ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Wed, Dec 10, 2008 at 8:23 AM, David Cole <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:18 PM, Bill Hoffman <[EMAIL PROTECTED]>wrote: > >> ... If you did not want to use python, you could use cmake >> -DCONFIG=${CMAKE_CFG_INTDIR} -E myscript.cmake... >> > > Make that: > cmake -DCONFIG=${CMAKE_CFG_INTDIR} -P myscript.cmake > > -P for *p*rocess script, not -E > Thanks for the help everybody, I really appreciate it! These DLL files are *not* built by CMake. They are third party libraries built elsewhere (On a different windows machine, even). I'm a bit skeptical to put the copy logic in Python because it only makes our build system more complex. People who know CMake now have to learn Python in order to work with our build system. The reason why I was passing in the configuration name itself and not the INTDIR is because I would be doing string compares on the configuration name itself to decide what libraries to copy over. A psuedo code example of what I'm talking about follows: if configuration == "debug" then copy "foo_d.dll" to INTDIR copy "bar_d.dll" to INTDIR else if configuration == "release" then copy "foo.dll" to INTDIR copy "bar.dll" to INTDIR end if Note that in both the 'debug' and 'release' cases, the INTDIR will properly reflect the "debug" executable directory and the "release" executable directory, respectively. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
I did a little more research into CMAKE_CFG_INTDIR and it's a little bit weird. First of all, it uses $(OutDir) in visual studio instead of $(IntDir) as the documentation says it will use. Secondly, the linker output file in Visual Studio is set as an absolute path instead of using $(OutDir). If I set CMAKE_ARCHIVE_OUTPUT_DIRECTORY for a static library, it changes my output file for the library to output to the correct directory in an absolute way, however $(OutDir) still remains the same, whereas it should reflect the changes made to the output directory in CMake. Why the inconsistency? By changing CMAKE_ARCHIVE_OUTPUT_DIRECTORY, I can no longer use CMAKE_CFG_INTDIR to figure out where the binaries will be placed at "post build event" time. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake