Re: [cmake-developers] Making Config.cmake files safer
On 11/12/2011 3:53 PM, David Cole wrote: And, in my opinion, if there are multiple possible causes of the problem then we should enumerate them in a message to the user, just as you've done here in this email back to me. And we should try to put them in the order of likelihood, so when they read it top-down, they read the smallest amount possible before having the a-ha moment where they realize what went wrong earlier. Yes. The wording needs to make it clear that this is *not* a problem with CMake or the files it generated or is loading. It is a problem with the path between CMake generating the files and them appearing on the user's disk. Instead of adding the code to the bottom of GenerateImportPropertyCode please create a separate method next to it for that part. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012578]: Parenthesis in source or build path causes Cmake-gui to fail the compiler tests
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12578 == Reported By:Jean-Christophe Houde Assigned To: == Project:CMake Issue ID: 12578 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-11-14 14:57 EST Last Modified: 2011-11-14 14:57 EST == Summary:Parenthesis in source or build path causes Cmake-gui to fail the compiler tests Description: When using the Cmake gui, specifying a source or build path with an opening parenthesis included causes the compiler tests to fail. Using the same path without a parenthesis works. Steps to Reproduce: 1. Create a project directory like the following /project (space) /src /build 2. Start Cmake-gui. 3. Use the absolute path of the src directory as the Where is the source code variable. 4. Use the absolute path of the build directory as the Where to build the binaries variable. 5. Use any basic CMakeList file. 6. Try to configure the project. It now should fail at the Check for working C compiler using: Xcode Check for working C compiler using: Xcode -- broken step. Additional Information: The error message is CMake Error at /Applications/CMake 2.8-6.app/Contents/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler /usr/bin/gcc is not able to compile a simple test program. It fails with the following output: Change Dir: /Users/houj2901/Documents/Recherche/Fibernavigator/trunk (test)/build-code/CMakeFiles/CMakeTmp Run Build Command:/Applications/CMake\ 2.8-6.app/Contents/bin/cmakexbuild -project CMAKE_TRY_COMPILE.xcodeproj build -target cmTryCompileExec -configuration Debug === BUILD NATIVE TARGET cmTryCompileExec OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug === Check dependencies CompileC CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec.build/Objects-normal/x86_64/testCCompiler.o testCCompiler.c normal x86_64 c com.apple.compilers.llvmgcc42 cd /Users/houj2901/Documents/Recherche/Fibernavigator/trunk (test)/build-code/CMakeFiles/CMakeTmp /Developer/usr/bin/llvm-gcc-4.2 -x c -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -O0 -mdynamic-no-pic -DCMAKE_INTDIR=Debug -isysroot /Developer/SDKs/MacOSX10.6.sdk -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2 -I/Users/houj2901/Documents/Recherche/Fibernavigator/trunk (test)/build-code/CMakeFiles/CMakeTmp/Debug/include -I/Users/houj2901/Documents/Recherche/Fibernavigator/trunk (test)/build-code/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec.build/DerivedSources/x86_64 -I/Users/houj2901/Documents/Recherche/Fibernavigator/trunk (test)/build-code/CMakeFiles/CMakeTmp/CMAKE_TRY** BUILD FAILED ** The following build commands failed: PhaseScriptExecution CMake PostBuild Rules CMAKE_TRY_COMPILE.build/Debug/cmTryCompileExec.build/Script-779D508F174847D09D396C67.sh (1 failure) == Issue History Date ModifiedUsername FieldChange == 2011-11-14 14:57 Jean-Christophe HoudeNew Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files safer
On Monday 14 November 2011, Brad King wrote: On 11/12/2011 3:53 PM, David Cole wrote: And, in my opinion, if there are multiple possible causes of the problem then we should enumerate them in a message to the user, just as you've done here in this email back to me. And we should try to put them in the order of likelihood, so when they read it top-down, they read the smallest amount possible before having the a-ha moment where they realize what went wrong earlier. Yes. The wording needs to make it clear that this is *not* a problem with CMake or the files it generated or is loading. It is a problem with the path between CMake generating the files and them appearing on the user's disk. Instead of adding the code to the bottom of GenerateImportPropertyCode please create a separate method next to it for that part. Done, in an updated version of the CheckImportedFileExistenceInConfigDotCMakeFiles branch. If there are no more objections, I'll merge tomorrow into next. Alex -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
Bill, I think the current incarnation of regexps in CMake should be kept for compatibility reasons. Adding PCRE is not difficult, just time consuming. The implementation I'd do would be an additional abstraction layer: - For the current BRE implementation, it would be a 1:1 call match - For the PCRE implementation, it would keep match status, count, next/previous iterators, etc. On Mon, Nov 14, 2011 at 7:30 PM, Bill Hoffman bill.hoff...@kitware.comwrote: Sorry for the top post... However, if the issue with ctest being slow can be fixed by using PCRE in CMake, that is good news. We can just link in the library, and replace that small part of CMake internal code that has the performance problem. This should not break backwards compatibility. It also gives us a way to slowly bring in PCRE into CMake. Alex, is there a way you can try PCRE in CMake to see if it fixes the problem? -Bill On 11/14/2011 1:13 PM, Pau Garcia i Quiles wrote: Hi, Check this: A wish a day 11: Perl Compatible Regular Expressions in CMake http://www.elpauer.org/?p=684 Unfortunately the student turned out to be a total fraud: he knew nothing about CMake, regular expressions (much less PCRE!), git, and could barely manage with C/C++. After months of explaining *really* basic stuff (such as the difference between a static and a shared library), he silently gave up. I do have an initial implementation and extensive information on how to implement PCRE in CMake. It's just I don't have enough spare time to do that, and at work I cannot justify investing so many time in CMake for free (for now, we don't need advanced regular expressions) On Mon, Nov 14, 2011 at 6:57 PM, Alexandru Ciobanu a...@rogue-research.com mailto:alex@rogue-research.**coma...@rogue-research.com wrote: Hi, Our team is affected by issue 0012381, that causes extremely poor performance by CTest. Details here: http://public.kitware.com/Bug/**view.php?id=12381http://public.kitware.com/Bug/view.php?id=12381 I've created a small test case that demonstrates the problem. Please find the .cpp file attached. From what I see, the RegularExpression class uses Henry Spencer regex implementation, which is known to be slow for some cases. On my machine, the attached example runs in 0.8 sec. Just to process one string! $ time ./repr real 0m0.865s user 0m0.862s sys 0m0.002s Grep can process 100k such strings in 0.5 sec (which includes reading a 570MB file from disk): $ wc -l big.str.txt 10 big.str.txt $ ls -lh big.str.txt -rw-r--r-- 1 alex staff 572M 14 Nov 12:30 big.str.txt $ time grep ([^:]+): warning[ \t]*[0-9]+[ \t]*: big.str.txt real 0m0.525s user 0m0.255s sys 0m0.269s I see three ways to fix this problem: A) use a trusted 3rd party regex library, like re2 or pcre B) find another self-contained regex implementation C) try to use the standard POSIX regex available in regex.h on most systems I tried to find another self-contained regex implementation, that we could use. I found Tiny REX, but it is as slow, in this case, as Henry Spencer's implementation. So what do you think is the best way to proceed about this problem? sincerely, Alex Ciobanu -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012579]: Improve project generator for eclipse to handle multiple top level directories
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12579 == Reported By:Dan Kegel Assigned To: == Project:CMake Issue ID: 12579 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2011-11-14 18:36 EST Last Modified: 2011-11-14 18:36 EST == Summary:Improve project generator for eclipse to handle multiple top level directories Description: See discussion at http://www.cmake.org/pipermail/cmake/2011-November/047435.html If CMakeLists.txt points to a distant directory, e.g. add_subdirectory(../foo foo) the projects generated by the existing cdt generator have two problems: 1) even if -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE is given, the ../foo directory is not exposed as a project in the gui 2) eclipse does not trigger a build when source files in directory ../foo are changed. The first problem can be solved by adding a dummy project in ../foo just as is done in the primary source directory (though, please, use a better name, like [_foo]) The second problem requires adding a link item in the main .project, pointing to the foo directory. I do those two things in a shell script after running cmake, but that means I have to re-run my shell script by hand after every change to any CMakeLists.txt, and it'd be nicer to have cmake's cdt generator do it for me. Steps to Reproduce: See example at http://code.google.com/p/winezeug/source/browse/trunk/cmake_examples/ex7/ == Issue History Date ModifiedUsername FieldChange == 2011-11-14 18:36 Dan Kegel New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On 11/14/2011 6:08 PM, Pau Garcia i Quiles wrote: Bill, I think the current incarnation of regexps in CMake should be kept for compatibility reasons. Yes, of course. Adding PCRE is not difficult, just time consuming. The implementation I'd do would be an additional abstraction layer: - For the current BRE implementation, it would be a 1:1 call match - For the PCRE implementation, it would keep match status, count, next/previous iterators, etc. So, for this case I would be interested to here from Alex to see if swapping out the regex will fix the ctest performance issue. It is a nice isolated place to give PCRE a try. -Bill -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On 11/12/2011 01:39 PM, David Cole wrote: For reference, the bug Mike refers to is this one: http://public.kitware.com/Bug/view.php?id=11258 I always use the manual technique of shutting down VS, running CMake, and then re-opening VS. It's really not that bad, once you get used to it. David C. Is it possibly an alternative to use cmake --build within an already configured build tree, provided the VS IDE is not strictly necessary? E.g., when porting a project from *nix to Windows, I usually open the VS shell, run CMake on the project's source tree from within a build directory and finally cmake --build .. For last-minute changes, I use the editor of my choice and invoke cmake --build . again. With Makefiles on *nix, this approach works as expected, but with VS, I noticed the following issue: The project is correctly rebuilt after a change in a source file, but a change in a CMakeLists.txt file only results in a regeneration of the solution and project files *without* recompiling or relinking anything, i.e. it is solely the ZERO_CHECK project which is rebuilt. In order to rebuild the actual targets, I need to specify the --clean-first option to cmake --build .. It seems as if a changed VS project file doesn't make VS recompile the affected source files, even if this is clearly necessary, e.g. due to changed preprocessor definitions. Is this behavior intended or VS-immanent, or should it be taken for buggy? Perhaps, a VS expert could shed some light on this matter; it'd be greatly appreciated. Regards, Michael On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson mike.jack...@bluequartz.net wrote: It is worse and better. 1: CMake will generate the VS projects and solutions every time it needs to run. DO NOT EDIT the generated VS projects and solutions. Add the requirements to the CMake files. 2: If you are on VS2007/VS2008 and you do a git pull and then switch to VS and click build a cmake check is run FIRST. If anything is different the new solution and project files are generated and then the build continues. You will get a dialog asking if you want to reload all of the projects. Things are pretty nice. 3: If you are on VS2010 there is now a long standing bug that seems to have no solution where you basically have to do the following: Close the VS solution git pull run cmake to regenerate the solution and projects Open the Solution and Compile. Yep. Sucks. Purchased VS2010 last year and have yet to use it because of that bug. If we (the cmake community**) were to actually figure out how to solve the problem then VS2010 would be as seamless as VS2008. Here is hoping for the future. ** I have kept track of the bug. Kitware and others have put a lot of time into trying to fix the bug. It just seams to be one of those elusive fixes that there just may not be a solution to. -- Mike Jackson www.bluequartz.net On Nov 11, 2011, at 5:30 PM, David Doria wrote: I typically work in KDevelop which has CMake support, so if another developer pushes some new files and changes to the CMakeLists.txt of my project, I simply 'git pull' the project and then click Build and it knows exactly what to do - it runs CMake and then builds the project. However, when working with Visual Studio, do I have to 'git pull', then go open cmake-gui from the VS2010E terminal, re-configure and re-generate the project, then reimport the VS2010E project, then build? This seems horribly awkward. And the reverse appears to have the same problem - if working inside VS I add a file to the VS project, how do I 'export' this addition back to the git repo? Thanks, 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] Problem with LINK_DIRECTORIES
Hi, For a static library target, I used TARGET_LINK_LIBRARIES and LINK_DIRECTORIES to link with a third party library. As we can see that in cmake, this linking information is propagated and used only in an executable/shared library target which depends on the former static library. But the issue is that only the TARGET_LINK_LIBRARIES is propagated and not the LINK_DIRECTORIES. This fails the linking of the executable/shared library target because it could not find the third party library. I found this problem when generating for visual studio 2005. The problem might be there in other platforms also. I feel that this behavior is an issue. Or am I missing something? Please let me know. Regards, Arun -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 11:46 AM, Arunmozhi wrote: Hi, For a static library target, I used TARGET_LINK_LIBRARIES and LINK_DIRECTORIES to link with a third party library. As we can see that in cmake, this linking information is propagated and used only in an executable/shared library target which depends on the former static library. But the issue is that only the TARGET_LINK_LIBRARIES is propagated and not the LINK_DIRECTORIES. This fails the linking of the executable/shared library target because it could not find the third party library. I found this problem when generating for visual studio 2005. The problem might be there in other platforms also. I feel that this behavior is an issue. Or am I missing something? Please let me know. Regards, Arun Hi Arun Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. Just pass the full path to the static library directly to TARGET_LINK_LIBRARIES. This is much more robust and will avoid these weird effects you are seeing. HTH Michael -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote: Hi Arun Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. I don't really agree with this advice. There are circumstances where link_directories() is absolutely necessary, so advocating to completely avoid it isn't really a one size fits all scenario. What I've done is make sure that link_directories() is called from a parent level directory, so that all projects inherit the directories. In cases where you do not have a hierarchy setup like this, then call link_directories() once with the same directories before each call to add_executable, add_library, etc. Also one unrelated note, but static libraries do not require any dependencies to be linked in when it is built. You only need your third party libraries in your shared library or executable that links against the static library in question. Hope this helps. -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 03:36 PM, Robert Dailey wrote: On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com mailto:them...@gmail.com wrote: Hi Arun Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. I don't really agree with this advice. There are circumstances where link_directories() is absolutely necessary, so advocating to completely avoid it isn't really a one size fits all scenario. Pray tell, what scenario would that be? I'm really curious, because I can't think of any... What I've done is make sure that link_directories() is called from a parent level directory, so that all projects inherit the directories. In cases where you do not have a hierarchy setup like this, then call link_directories() once with the same directories before each call to add_executable, add_library, etc. Also one unrelated note, but static libraries do not require any dependencies to be linked in when it is built. You only need your third party libraries in your shared library or executable that links against the static library in question. The OP is talking about such a setup a/CMakelists.txt: add_library(a STATIC a.c) # a uses foo internally, but doesn't expose this fact in its interface. # clients of a should not need to know about a's implementation details, # which is why we declare this dependency here and let CMake handle the # rest. target_link_libraries(a foo) b/CMakeLists.txt - add_executable(b b.c) target_link_libraries(b a) Michael -- 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
Re: [CMake] CMake single-configuration makefiles
On 11/13/2011 11:30 PM, Eric Noulard wrote:
2011/11/13 Robert Dailey rcdai...@gmail.com:
I understand that currently Makefiles generated by CMake are
single-configuration by-design. In other words, you can't issue a debug or
release command to make, you have to regenerate for a different
configuration.
For this purpose you can use 2 build trees that use the same source tree
cd /path/to/source
mkdir dbuild
cd dbuild
cmake -DCMAKE_BUILD_TYPE=Debug ..
cd ..
mkdir rbuild
cd rbuild
cmake -DCMAKE_BUILD_TYPE=Release ..
now to build debug
cd dbuild; make
and to build release
cd rbuild; make
Can someone explain the reason for this design?
Don't know in the past I used makefile that can deal with multiple config,
everytime it was a re-entrant makefile scheme. May be this should be
avoided in order to produce 'portable' makefiles?
Are there any plans to change it?
Don't know.
But may be it would be nice to have a way to create
several build trees at one time for that and produce a unifying
top level makefile that drive them all.
One can nearly achieve this by now; see the following example:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MULTICONFIG C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# --
IF(CMAKE_CONFIGURATION_TYPES)
ADD_CUSTOM_TARGET(configs)
ADD_CUSTOM_TARGET(builds)
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/${i})
ADD_CUSTOM_TARGET(config-${i}
COMMAND ${CMAKE_COMMAND} ${PROJECT_SOURCE_DIR}
-DCMAKE_BUILD_TYPE=${i}
-DCACHE_DIR=${PROJECT_BINARY_DIR}
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${i})
ADD_DEPENDENCIES(configs config-${i})
ADD_CUSTOM_TARGET(build-${i}
COMMAND ${CMAKE_COMMAND} --build ${PROJECT_BINARY_DIR}/${i})
ADD_DEPENDENCIES(builds build-${i})
ENDFOREACH()
FOREACH(i IN LISTS FORWARD)
ADD_CUSTOM_TARGET(${i}
COMMAND ${CMAKE_COMMAND} --build \${CONFIG} --target ${i})
ENDFOREACH()
ADD_CUSTOM_TARGET(world ALL
COMMAND ${CMAKE_COMMAND} --build \${CONFIG})
RETURN()
ENDIF()
IF(DEFINED CACHE_DIR)
LOAD_CACHE(${CACHE_DIR}
EXCLUDE CMAKE_BUILD_TYPE CMAKE_CONFIGURATION_TYPES)
ENDIF()
# --
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS_DEBUG DEBUG
COMPILE_DEFINITIONS_RELEASE RELEASE)
/* main.c: */
int main(void){return 0;}
The part to add in order to enable multiple build trees is between
-- and --. The basic idea is: If CMAKE_CONFIGURATION_TYPES is
defined, create a build tree for each entry along with a custom target
which configures that tree with the correct CMAKE_BUILD_TYPE. Also, add
a custom target which builds that tree via cmake --build. These build
trees' configurations must be a separate step - therefore, driven by a
custom target - because the top-level configuration has to be finished
to enable the several build trees to load the cache via LOAD_CACHE();
otherwise, the initial -D settings would not be forwarded. For these
reasons, we need the CACHE_DIR variable, and the RETURN() statement
disables the actual part of the CMakeLists.txt file in the top-level
configuration. Obviously, CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPES
must not be loaded from the cache to the build trees. A downside is
that you must implement your own, say, target forwarding if you
want to be able to say main TARGET CONFIG=debug; the FORWARD
variable with a list of targets to be forwarded is used for this
purpose. To see the project in action, go to an empty top-level
build directory and issue, e.g.:
cmake srcdir \
-DCMAKE_CONFIGURATION_TYPES=debug;release;custom \
-DCMAKE_C_FLAGS_CUSTOM=-DCUSTOM \
-DFORWARD=main
This will create the subdirectories {debug,release,custom}; now
make configs
to configure the different build trees and load the cache from the
top-level configuration. Subsequently, you can say make builds to
build all configurations, or cmake --build config to build only
one, or make main CONFIG=CONFIG or even make CONFIG=CONFIG.
Anyway, although the addition to mimic the behavior of a real multi-
configuration generator to the Makefiles ones is no big deal, I'm
in doubt if it's worth the effort. Personally, I'm fine with the
Makefiles generators' single-configuration limitation.
Regards,
Michael
I'm new to Makefiles so I'm curious to learn as much as possible
about it.
If you are new to makefile may be you can have a look at
the chapter 4 of this book
http://www.informit.com/store/product.aspx?isbn=0130091154
it is about GNU make but it contains valuable introduction to makefile
and the book may downloaded:
http://ptgmedia.pearsoncmg.com/images/0130091154/downloads/0130091154.zip
--
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:
Re: [CMake] CMAKE_RUNTIME_OUTPUT_DIRECTORY best practice for Windows and Visual Studio
On 13 November 2011 19:51, Niels Dekker - address until 2014
niels_dekker_address_until_2...@xs4all.nl wrote:
Mateusz Loskot wrote:
On Windows, I use Visual Studio for development, so I have
CMake-generated .sln with projects. loaded into the IDE. I build.
Then, I'd like to run one of executables (e.g. test.exe) which links against
the DLLs also
built by the project. Obviously, it is necessary to deal with the run-time
search path.
At the moment, I simplify things by outputting all .exe and .dll
binaries to common directory, so programs can find required DLLs:
set(MYPRJOUTDIR ${PROJECT_BINARY_DIR}/bin/${CMAKE_BUILD_TYPE})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${MYPRJOUTDIR})
On Windows, it looks fine to me to have all the DLL's built by the project
together with the executable that links against them, in one and the same
CMAKE_RUNTIME_OUTPUT_DIRECTORY.
Good, I'm glad it's nothing weird neither wrong in this approach.
The alternative of setting the PATH looks
less reliable to me, because the PATH may easily be overruled by other
locations (current directory, system directory or Windows directory),
depending on that rather complicated Dynamic-Link Library Search Order
thing, http://msdn.microsoft.com/en-us/site/ms682586 And eventually I guess
you don't want your application to depend on the PATH at the end user machine.
Yes, you are right.
I have some projects configured in such way they try to generate
.vcproj.user file
which defines PATH with pointers to location of run-time dependencies.
For example: https://github.com/libLAS/libLAS/tree/master/cmake
However, I haven't yet tried to build an isolated application
according to your reference [3]
(http://msdn.microsoft.com/en-us/library/aa375190%28VS.85%29.aspx).
Would you recommend doing so?
Niels, I haven't tried it myself neither. I don't have experience with
this technique,
so I can't say if it is recommended.
Actually, I hoped to receive a related piece of advice here, from CMake users.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
--
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote: On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote: Hi Arun Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. I don't really agree with this advice. There are circumstances where link_directories() is absolutely necessary, so advocating to completely avoid it isn't really a one size fits all scenario. I agree with the advice entirely. link_directories is completely *un*necessary if you follow the other advice which is to always use full path names to library files (or CMake target names) when calling target_link_libraries. I never use link_directories. What I've done is make sure that link_directories() is called from a parent level directory, so that all projects inherit the directories. In cases where you do not have a hierarchy setup like this, then call link_directories() once with the same directories before each call to add_executable, add_library, etc. Also one unrelated note, but static libraries do not require any dependencies to be linked in when it is built. You only need your third party libraries in your shared library or executable that links against the static library in question. Hope this helps. -- 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 -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote: On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote: On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote: Hi Arun Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. I don't really agree with this advice. There are circumstances where link_directories() is absolutely necessary, so advocating to completely avoid it isn't really a one size fits all scenario. I agree with the advice entirely. link_directories is completely *un*necessary if you follow the other advice which is to always use full path names to library files (or CMake target names) when calling target_link_libraries. I never use link_directories. Well maybe you can tell me I'm doing this wrong then, but based on how I am currently setting up my third party libraries, it is required. So basically all third party libraries we use are not installed individually, instead we have a server on our intranet that contains precompiled versions of all libraries in a specific and consistent hierarchy. For this reason, it doesn't make sense to use find_library(), which would normally always give you absolute paths to your library files and thus link_directories() would not be needed. Instead I have a script in CMake that iterates each third party library and adds its lib link directory to a list. When done I take this whole list of link directories and pass it to link_directories() in my top level CMakeLists file, this way each and every project will include all of the third party library lib directories to have access to them. For each target I simply create a list of my libs, like so: set( libraries zlib libbdb47 ) I pass each one of these to target_link_libraries() and I leave it up to the compiler to search for where to find the file in the provided link directories. -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
On 14 November 2011 17:17, Robert Dailey rcdai...@gmail.com wrote: So basically all third party libraries we use are not installed individually, instead we have a server on our intranet that contains precompiled versions of all libraries in a specific and consistent hierarchy. For this reason, it doesn't make sense to use find_library(), which would normally always give you absolute paths to your library files and thus link_directories() would not be needed. A typical Linux user can say the same: I have all my libraries in /usr/lib so it does not make sense to use find_library. No point arguing if it would make sense or not. Simply, find_library is a unified convention used by CMake, it works regardless user-specific filesystem structure. Simply, it would not hurt to use find_library(). Then, you can follow the CMake convention, without a need of custom scripts, etc. I pass each one of these to target_link_libraries() and I leave it up to the compiler to search for where to find the file in the provided link directories. IMO, you don't buy anything with this customisation. Either CMake finds library and tells compiler look, it's here or CMake + custom script approximates library location and lets linker to find it. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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
Re: [CMake] Adding a new language
If the -c option is given, specify the name of the object file produced for the next source file that appears on the command line. So if the help says that -o is supposed to do something sensible when used with -c but it doesn't, I'd suggest to file a bug. Note that the order of arguments may be important. Duh! Thanks for insisting: it works! I'd still like to know how to explain to cmake that the command produces 2 files, but at least I can get rid of my hack. Stefan happier -- 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] Libraries with custom build command
What is the recommended way to define libraries with custom build commands?
This trick seems to be the only way:
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
endif()
add_library(foo dummy.cpp)
add_custom_command(TARGET foo POST_BUILD
COMMAND my command to replace the dummy libfoo
)
Is it normal that kind of thing is not possible with IMPORTED libraries?
--
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
Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 06:17 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote:
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote:
Hi Arun
Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
I don't really agree with this advice. There are circumstances where
link_directories() is absolutely necessary, so advocating to completely
avoid it isn't really a one size fits all scenario.
I agree with the advice entirely. link_directories is completely
*un*necessary if you follow the other advice which is to always use
full path names to library files (or CMake target names) when calling
target_link_libraries.
I never use link_directories.
Well maybe you can tell me I'm doing this wrong then, but based on how I am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use find_library(),
which would normally always give you absolute paths to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party library and
adds its lib link directory to a list. When done I take this whole list of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of the
third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up to
the compiler to search for where to find the file in the provided link
directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Regards,
Michael
--
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.dewrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use find_library(),
which would normally always give you absolute paths to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party library
and
adds its lib link directory to a list. When done I take this whole list
of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of the
third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up to
the compiler to search for where to find the file in the provided link
directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about
20 of them. This to me is the same as just generating a list of directories
and including those directly, and a lot less trouble.
find_library() is great and I really wanted to use it for this, but to me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs the
third party libraries in different locations on each of their machines, and
different versions, it makes more sense to use it in that case.
Why should I let CMake search find a library when I already know where it
is? Simply to get absolute paths to those libraries? If I want absolute
paths I can think of much better ways to do it, preferably through string
concatenation.
Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided by CMake. This means I'd end up writing
80% of the find modules myself. This is a lot of work for no perceived
benefit.
With my points made and circumstances explained, can you still give me a
good reason to use find_library?
I understand and agree with the issues that come with using
link_directories(), however I haven't run into those issues yet and our
consistent organization of third party libraries on our intranet server are
carry over from our legacy build system that I'm replacing.
--
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Monday 14 November 2011, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
mhertl...@online.dewrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how
I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use
find_library(), which would normally always give you absolute paths to
your library files and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party library
and
adds its lib link directory to a list. When done I take this whole list
of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of
the third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up
to the compiler to search for where to find the file in the provided
link directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about
20 of them. This to me is the same as just generating a list of directories
and including those directly, and a lot less trouble.
You can set CMAKE_PREFIX_PATH, and cmake will automatically look in the lib/
and include/ subdirectories of those.
Alex
--
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
Re: [CMake] Problem with LINK_DIRECTORIES
If you already know where all the libraries are, please just use the
full paths to those libraries, and do not use find_library.
On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.de
wrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use find_library(),
which would normally always give you absolute paths to your library
files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party library
and
adds its lib link directory to a list. When done I take this whole list
of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of the
third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up to
the compiler to search for where to find the file in the provided link
directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about 20
of them. This to me is the same as just generating a list of directories and
including those directly, and a lot less trouble.
find_library() is great and I really wanted to use it for this, but to me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs the
third party libraries in different locations on each of their machines, and
different versions, it makes more sense to use it in that case.
Why should I let CMake search find a library when I already know where it
is? Simply to get absolute paths to those libraries? If I want absolute
paths I can think of much better ways to do it, preferably through string
concatenation.
Another issue is that 80% of the libraries we use do not have a pre-packaged
Find module provided by CMake. This means I'd end up writing 80% of the find
modules myself. This is a lot of work for no perceived benefit.
With my points made and circumstances explained, can you still give me a
good reason to use find_library?
I understand and agree with the issues that come with using
link_directories(), however I haven't run into those issues yet and our
consistent organization of third party libraries on our intranet server are
carry over from our legacy build system that I'm replacing.
--
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
--
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
Re: [CMake] Adding a new language
On 2011-11-14 13:30-0500 Stefan Monnier wrote: I'd still like to know how to explain to cmake that the command produces 2 files, but at least I can get rid of my hack. That (assuming just a simple object file is produced by compilation) is one of several general limitations with CMake language support. For example, my understanding is this issue has been taken care of for Fortran 95 (where compilation produces both object and module files) with Fortran-95 specific changes to the C++ cmake code. But I would far prefer to see a generic mechanism for this to not only to deal with the Fortran 95 module issue, but also the compilation-generated Ada library identification (*.ali) files, and also the similar issue for OCaml compiler generated files that you have described. Because of this and other struggles I had trying to implement Ada language support for CMake, I didn't even consider implementing CMake language support for OCaml for the PLplot OCaml bindings. Instead we currently use (many!) custom commands and targets for that case, but I would be happy to change to your CMake OCaml language support if/when that works. Here is what I suggest you do to move forward with that project. Present a complete summary of your OCaml compilation needs for the CMake developers. That is, state what commands are used to build libraries, what commands are used to build executables, what kinds of files are generated for each stage of each kind of build, and what directories need to be identified at each stage of the build to gain access to files generated in previous stages of the build process. Furthermore, a complicating factor with OCaml is there are two kinds of executables (and libraries?) based on whether ocamlc or ocamlopt is used to respectively produce bytecode executable files that are executed with the OCaml interpreter (ocamlrun) or native executable files that are executed with the ordinary run-time loader. If there are different generic build needs for ocamlc versus ocamlopt be sure to include those differences in your summary. If you are willing to make such an OCaml summary, I would be willing to do the same thing for Ada to make our joint case to the CMake developers of what kind of additional generic language support is needed by CMake to deal with the complicated build needs of languages such as OCaml and Ada (and Fortran 95) in a completely generic way. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
That's what I do sometimes. To make that easier, CMake gives some convenience
variables for library prefixes and suffixes if you are on multiple platforms.
Clint
On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
If you already know where all the libraries are, please just use the
full paths to those libraries, and do not use find_library.
On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.de
wrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how
I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use
find_library(), which would normally always give you absolute paths
to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party
library and
adds its lib link directory to a list. When done I take this whole
list of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of
the third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up
to the compiler to search for where to find the file in the provided
link directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about
20 of them. This to me is the same as just generating a list of
directories and including those directly, and a lot less trouble.
find_library() is great and I really wanted to use it for this, but to me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs
the third party libraries in different locations on each of their
machines, and different versions, it makes more sense to use it in that
case.
Why should I let CMake search find a library when I already know where
it is? Simply to get absolute paths to those libraries? If I want
absolute paths I can think of much better ways to do
it, preferably through string concatenation.
Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided by CMake. This means I'd end up
writing 80% of the find modules myself. This is a lot of work for no
perceived benefit.
With my points made and circumstances explained, can you still give me a
good reason to use find_library?
I understand and agree with the issues that come with using
link_directories(), however I haven't run into those issues yet and our
consistent organization of third party libraries on our intranet server
are carry over from our legacy build system that I'm replacing.
--
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
--
Powered by
Re: [CMake] Problem with LINK_DIRECTORIES
What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?
-
Robert Dailey
On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson clin...@elemtech.comwrote:
That's what I do sometimes. To make that easier, CMake gives some
convenience
variables for library prefixes and suffixes if you are on multiple
platforms.
Clint
On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
If you already know where all the libraries are, please just use the
full paths to those libraries, and do not use find_library.
On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey rcdai...@gmail.com
wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.de
wrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on
how
I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use
find_library(), which would normally always give you absolute paths
to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party
library and
adds its lib link directory to a list. When done I take this whole
list of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of
the third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you
might
set up one variable for each library containing the latter's full
path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate
CMakeLists.txt
files and, thus, will be known wherever they are needed in your
project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it
up
to the compiler to search for where to find the file in the provided
link directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide
hint
search directories for each and every single library, and there are
about
20 of them. This to me is the same as just generating a list of
directories and including those directly, and a lot less trouble.
find_library() is great and I really wanted to use it for this, but to
me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs
the third party libraries in different locations on each of their
machines, and different versions, it makes more sense to use it in that
case.
Why should I let CMake search find a library when I already know
where
it is? Simply to get absolute paths to those libraries? If I want
absolute paths I can think of much better ways to do
it, preferably through string concatenation.
Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided by CMake. This means I'd end up
writing 80% of the find modules myself. This is a lot of work for no
perceived benefit.
With my points made and circumstances explained, can you still give me
a
good reason to use find_library?
I understand and agree with the issues that come with using
link_directories(), however I haven't run into those issues yet and our
consistent organization of third party libraries on our intranet server
are carry over from our legacy build system that I'm replacing.
--
Powered by www.kitware.com
Visit
Re: [CMake] Problem with LINK_DIRECTORIES
From the Modules/Platform/* files, it looks like the only difference between
the
two is when using CYGWIN or MinGW. I'm not sure which to use.
Clint
On Monday, November 14, 2011 01:51:49 pm Robert Dailey wrote:
What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?
-
Robert Dailey
On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson
clin...@elemtech.comwrote:
That's what I do sometimes. To make that easier, CMake gives some
convenience
variables for library prefixes and suffixes if you are on multiple
platforms.
Clint
On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
If you already know where all the libraries are, please just use the
full paths to those libraries, and do not use find_library.
On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey rcdai...@gmail.com
wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
mhertl...@online.de
wrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on
how
I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that
contains precompiled versions of all libraries in a specific and
consistent hierarchy. For this reason, it doesn't make sense to
use
find_library(), which would normally always give you absolute
paths to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party
library and
adds its lib link directory to a list. When done I take this whole
list of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all
of the third party library lib directories to have access to
them.
Instead of populating a list with the libraries' directories, you
might
set up one variable for each library containing the latter's full
path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the
top-level CMakeLists.txt, these variables propagate to subordinate
CMakeLists.txt
files and, thus, will be known wherever they are needed in your
project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it
up
to the compiler to search for where to find the file in the
provided link directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide
hint
search directories for each and every single library, and there are
about
20 of them. This to me is the same as just generating a list of
directories and including those directly, and a lot less trouble.
find_library() is great and I really wanted to use it for this, but
to
me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user
installs the third party libraries in different locations on each of
their machines, and different versions, it makes more sense to use
it in that case.
Why should I let CMake search find a library when I already know
where
it is? Simply to get absolute paths to those libraries? If I want
absolute paths I can think of much better ways to do
it, preferably through string concatenation.
Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided by CMake. This means I'd end up
writing 80% of the find modules myself. This is a lot of work for no
perceived benefit.
With my points made and circumstances
Re: [CMake] Multiple source directory scenario and cdt generator
On Sat, Nov 12, 2011 at 11:04 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Ok. So two things: * please give current cmake master a try, it has several improvements. * please create a ticket in the cmake bug tracker for this, improved source- project generator for Eclipse, or something like this. My goal is to have no open bugs for Eclipse when 2.8.7 wil be released. OK, I filed http://public.kitware.com/Bug/view.php?id=12579 for this I'll give cmake master a spin sometime this week. -- 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-commits] CMake branch, next, updated. v2.8.6-1867-g324f819
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 324f819fecfda80a014da2bf82d82b662d0226d1 (commit)
via 365b613f91da1844cb7daee9aee39559ec06c7c8 (commit)
via a8f6159f69dbfdacf4d48ff26f21862d83fa7fd8 (commit)
from 9958122422b06d3056c272d908c0663202ece472 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=324f819fecfda80a014da2bf82d82b662d0226d1
commit 324f819fecfda80a014da2bf82d82b662d0226d1
Merge: 9958122 365b613
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 14 07:59:25 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 14 07:59:25 2011 -0500
Merge topic 'import-KWIML' into next
365b613 Merge branch 'upstream-kwiml' into import-KWIML
a8f6159 KWIML: Create test output dir for Xcode
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=365b613f91da1844cb7daee9aee39559ec06c7c8
commit 365b613f91da1844cb7daee9aee39559ec06c7c8
Merge: e2a0455 a8f6159
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 14 07:58:31 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 14 07:58:31 2011 -0500
Merge branch 'upstream-kwiml' into import-KWIML
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8f6159f69dbfdacf4d48ff26f21862d83fa7fd8
commit a8f6159f69dbfdacf4d48ff26f21862d83fa7fd8
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 14 07:53:06 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 14 07:54:10 2011 -0500
KWIML: Create test output dir for Xcode
Xcode 2.x forgets to create the target output directory before linking
the individual architecture pieces of a universal binary for the target
KWIML_test. Then it passes the directory to -L and -F options when
linking the and warns that the directory does not exist. We work around
the problem by using a pre-build rule on the target to create the output
directory.
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index 15816cf..febc994 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -56,3 +56,13 @@ set_property(TARGET ${KWIML}_test PROPERTY
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
add_test(${KWIML}.test ${CMAKE_CURRENT_BINARY_DIR}/${KWIML}_test)
set_property(TEST ${KWIML}.test PROPERTY LABELS ${KWIML_LABELS_TEST})
+
+# Xcode 2.x forgets to create the output directory before linking
+# the individual architectures.
+if(CMAKE_OSX_ARCHITECTURES AND XCODE
+AND NOT ${XCODE_VERSION} MATCHES ^[^12])
+ add_custom_command(
+TARGET ${KWIML}_test
+PRE_BUILD COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CFG_INTDIR}
+)
+endif()
---
Summary of changes:
Utilities/KWIML/test/CMakeLists.txt | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.6-1872-g98094a2
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 98094a28c599c9d9faa13bb38a9989be7bcabefa (commit)
via c92ffece804cd177c3531e58a39c3f0a6487d67d (commit)
via 1be4b6f4638334970a3d3f19891b5997ddcf5717 (commit)
from 479f502428937e8f30b47afa824836eac4206c8f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98094a28c599c9d9faa13bb38a9989be7bcabefa
commit 98094a28c599c9d9faa13bb38a9989be7bcabefa
Merge: 479f502 c92ffec
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 14 10:12:44 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 14 10:12:44 2011 -0500
Merge topic 'vs-version-ivar' into next
c92ffec Enumerate VS11 version explicitly in local generators
1be4b6f Order VS local generator Version ivar values consistently
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c92ffece804cd177c3531e58a39c3f0a6487d67d
commit c92ffece804cd177c3531e58a39c3f0a6487d67d
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 14 09:42:51 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 14 09:50:47 2011 -0500
Enumerate VS11 version explicitly in local generators
Since the parent commit the local generator Version ivar may be
compared for ordering. Convert comparisons:
==VS10 becomes =VS10
!=VS10 becomes VS10
to support an explicit enumeration value for VS11 with no change
in behavior.
diff --git a/Source/cmGlobalVisualStudio11Generator.cxx
b/Source/cmGlobalVisualStudio11Generator.cxx
index 97308bb..be7fd55 100644
--- a/Source/cmGlobalVisualStudio11Generator.cxx
+++ b/Source/cmGlobalVisualStudio11Generator.cxx
@@ -10,6 +10,7 @@
See the License for more information.
*/
#include cmGlobalVisualStudio11Generator.h
+#include cmLocalVisualStudio10Generator.h
#include cmMakefile.h
//
@@ -36,6 +37,16 @@ void
cmGlobalVisualStudio11Generator::WriteSLNHeader(std::ostream fout)
}
//
+cmLocalGenerator *cmGlobalVisualStudio11Generator::CreateLocalGenerator()
+{
+ cmLocalVisualStudio10Generator* lg =
+new cmLocalVisualStudio10Generator(cmLocalVisualStudioGenerator::VS11);
+ lg-SetPlatformName(this-GetPlatformName());
+ lg-SetGlobalGenerator(this);
+ return lg;
+}
+
+//
void cmGlobalVisualStudio11Generator
::GetDocumentation(cmDocumentationEntry entry) const
{
diff --git a/Source/cmGlobalVisualStudio11Generator.h
b/Source/cmGlobalVisualStudio11Generator.h
index 14019a7..7e8f6aa 100644
--- a/Source/cmGlobalVisualStudio11Generator.h
+++ b/Source/cmGlobalVisualStudio11Generator.h
@@ -35,6 +35,9 @@ public:
/** Get the documentation entry for this generator. */
virtual void GetDocumentation(cmDocumentationEntry entry) const;
+ ///! create the correct local generator
+ virtual cmLocalGenerator *CreateLocalGenerator();
+
/** TODO: VS 11 user macro support. */
virtual std::string GetUserMacrosDirectory() { return ; }
protected:
diff --git a/Source/cmLocalVisualStudioGenerator.h
b/Source/cmLocalVisualStudioGenerator.h
index 9794d59..fcf1f21 100644
--- a/Source/cmLocalVisualStudioGenerator.h
+++ b/Source/cmLocalVisualStudioGenerator.h
@@ -37,7 +37,8 @@ public:
VS71 = 71,
VS8 = 80,
VS9 = 90,
-VS10 = 100
+VS10 = 100,
+VS11 = 110
};
cmLocalVisualStudioGenerator(VSVersion v);
diff --git a/Source/cmVisualStudioGeneratorOptions.cxx
b/Source/cmVisualStudioGeneratorOptions.cxx
index a3bf0ed..41230e7 100644
--- a/Source/cmVisualStudioGeneratorOptions.cxx
+++ b/Source/cmVisualStudioGeneratorOptions.cxx
@@ -65,6 +65,7 @@ void
cmVisualStudioGeneratorOptions::FixExceptionHandlingDefault()
this-FlagMap[ExceptionHandling] = FALSE;
break;
case cmLocalVisualStudioGenerator::VS10:
+case cmLocalVisualStudioGenerator::VS11:
// by default VS puts ExceptionHandling/ExceptionHandling empty
// for a project, to make our projects look the same put a new line
// and space over for the closing /ExceptionHandling as the default
@@ -211,7 +212,7 @@ cmVisualStudioGeneratorOptions
{
return;
}
- if(this-Version == cmLocalVisualStudioGenerator::VS10)
+ if(this-Version = cmLocalVisualStudioGenerator::VS10)
{
// if there are configuration specifc flags, then
// use the
[Cmake-commits] CMake branch, next, updated. v2.8.6-1874-gc10deda
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c10dedab552492299476ec1b9428c36581ac62b5 (commit)
via b688f114c9b3c951c6d4640412d33b70974a1dc6 (commit)
from 98094a28c599c9d9faa13bb38a9989be7bcabefa (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c10dedab552492299476ec1b9428c36581ac62b5
commit c10dedab552492299476ec1b9428c36581ac62b5
Merge: 98094a2 b688f11
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Mon Nov 14 12:00:20 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 14 12:00:20 2011 -0500
Merge topic 'qt4-deploy-module' into next
b688f11 Check QtCore without warning.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b688f114c9b3c951c6d4640412d33b70974a1dc6
commit b688f114c9b3c951c6d4640412d33b70974a1dc6
Author: Mike McQuaid m...@mikemcquaid.com
AuthorDate: Mon Nov 14 16:34:10 2011 +
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Mon Nov 14 10:00:08 2011 -0700
Check QtCore without warning.
When debug and release versions of QtCore were available it printed
a warning. This has been fixed.
diff --git a/Modules/DeployQt4.cmake b/Modules/DeployQt4.cmake
index 4bf1b6c..5350301 100644
--- a/Modules/DeployQt4.cmake
+++ b/Modules/DeployQt4.cmake
@@ -250,7 +250,11 @@ function(install_qt4_executable executable)
endif()
get_filename_component(executable_absolute ${executable} ABSOLUTE)
-gp_file_type(${executable_absolute} ${QT_QTCORE_LIBRARY}
qtcore_type)
+if(EXISTS ${QT_QTCORE_LIBRARY_RELEASE})
+gp_file_type(${executable_absolute}
${QT_QTCORE_LIBRARY_RELEASE} qtcore_type)
+elseif(EXISTS ${QT_QTCORE_LIBRARY_DEBUG})
+gp_file_type(${executable_absolute} ${QT_QTCORE_LIBRARY_DEBUG}
qtcore_type)
+endif()
if(qtcore_type STREQUAL system)
set(qt_plugins_dir )
endif()
---
Summary of changes:
Modules/DeployQt4.cmake |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
