Re: [cmake-developers] WindowsCE
On 11/28/2012 09:03 AM, Patrick Gansterer wrote: It looks like you're adding new cmake -E windowsce_environment8 cmake -E windowsce_environment9 commands that print out the environment settings. That looks okay to me, but is there no vsvars32.bat equivalent? No, that's the reason for this. Any better name for this commands? I have no strong preference, but perhaps cmake -E env_vs8_wince cmake -E env_vs9_wince to set a precedent for env_ commands that generate environments. -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] Policy for INTERFACE_LINK_LIBRARIES
Hi Stephen, I've looked through the add-INTERFACE_LINK_LIBRARIES-property topic. Unless I'm misunderstanding something I think we can simplify CMP0019 quite a bit. What made it complicated in earlier discussions was a desire to generate and export INTERFACE_LINK_LIBRARIES even from projects that have not been modified to be aware of it. However, your implementation does not reflect this, which IMO is good. In cmExport*.cxx you're generating INTERFACE_LINK_LIBRARIES only when CMP0019 is NEW in the producing project. Once the policy has been set to NEW then we know the project has been modified and can assume the authors are aware of CMake 2.8.11 and the policy. In that case we can assume they set or dropped any old LINK_INTERFACE_LIBRARIES according to their own needs to support consuming projects and older CMake versions. I think we can drop the consumer-side policy completely. Consumers will load imported targets with the old and/or new interfaces specified as chosen by the producing project. CMake 2.8.11 will just use the old interface. CMake = 2.8.11 will just use the new interface if it is available and otherwise fall back to the old. The burden of compatibility with existing consumer releases falls on the authors modifying the producing project, just as with any other change they make. We can re-work CMP0019 to work purely in the producing (exporting) project. If the policy is set to OLD we export only the old interface. If the policy is set to NEW then we export the old and new interfaces. If the policy is not set then we evaluate/compare the interfaces and warn if they are different, but still export only the old interface. I'm still not sure how we can eventually stop exporting the old interface. Perhaps the export() and install(EXPORT) commands can learn new options to specify the minimum supported version of CMake for their consumers. We can wait and tackle this later though. Thoughts? -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 0013754]: Ninja: Framework paths are not correctly added to g++ commandline args.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13754
==
Reported By:Edward Rudd
Assigned To:
==
Project:CMake
Issue ID: 13754
Category: CMake
Reproducibility:always
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2012-11-28 23:31 WAST
Last Modified: 2012-11-28 23:31 WAST
==
Summary:Ninja: Framework paths are not correctly added to
g++ commandline args.
Description:
I have a project that uses a custom framework path to find OS X frameworks.
When using the ninja generator the -F/path/to/framework/path is not added to the
GCC command line causing compiles to fail.
Steps to Reproduce:
FIND_LIBRARY(SDL2_LIBRARY SDL2
PATHS SDL2/lib/osx)
MARK_AS_ADVANCED(SDL2_LIBRARY)
ADD_LIBRARY(Lib STATIC
${SOURCE}
)
TARGET_LINK_LIBRARIES(Lib ${SDL2_LIBRARY} )
Additional Information:
This is the C++ command called when using the unix makefile generator (paths
changed to protect the innocent)
/usr/bin/c++ -D_DEV -g -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-I/path/to/source/src/..-F/path/to/source/SDL2/lib/osx -o
CMakeFiles/Lib.dir/SDL2Threading.cpp.o -c /path/to/source/src/SDL2Threading.cpp
This is that ninja called
/usr/bin/c++ -D_DEV -g
-arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-I/path/to/source/src/..
-MMD -MT Lib/CMakeFiles/Lib.dir/SDL2Threading.cpp.o
-MF Lib/CMakeFiles/Lib.dir/SDL2Threading.cpp.o.d
-o Lib/CMakeFiles/Lib.dir/SDL2Threading.cpp.o
-c /path/to/source/src/SDL2Threading.cpp
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-28 23:31 Edward RuddNew 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] Policy for INTERFACE_LINK_LIBRARIES
Brad King wrote: Hi Stephen, I've looked through the add-INTERFACE_LINK_LIBRARIES-property topic. Unless I'm misunderstanding something I think we can simplify CMP0019 quite a bit. What made it complicated in earlier discussions was a desire to generate and export INTERFACE_LINK_LIBRARIES even from projects that have not been modified to be aware of it. Yes, I think you might be right there. However, your implementation does not reflect this, which IMO is good. In cmExport*.cxx you're generating INTERFACE_LINK_LIBRARIES only when CMP0019 is NEW in the producing project. Once the policy has been set to NEW then we know the project has been modified and can assume the authors are aware of CMake 2.8.11 and the policy. In that case we can assume they set or dropped any old LINK_INTERFACE_LIBRARIES according to their own needs to support consuming projects and older CMake versions. I think we can drop the consumer-side policy completely. Consumers will load imported targets with the old and/or new interfaces specified as chosen by the producing project. CMake 2.8.11 will just use the old interface. CMake = 2.8.11 will just use the new interface if it is available and otherwise fall back to the old. The burden of compatibility with existing consumer releases falls on the authors modifying the producing project, just as with any other change they make. Yes. We can re-work CMP0019 to work purely in the producing (exporting) project. If the policy is set to OLD we export only the old interface. If the policy is set to NEW then we export the old and new interfaces. If the policy is not set then we evaluate/compare the interfaces and warn if they are different, but still export only the old interface. I'm still not sure how we can eventually stop exporting the old interface. Perhaps the export() and install(EXPORT) commands can learn new options to specify the minimum supported version of CMake for their consumers. We can wait and tackle this later though. I guess the old interface is not exported if it is unset, so if the producer stops populating the old interface, they stop exporting it too. The problem is we'd need to provide a way for them to not populate the old interface. Having them port away from set_property(TARGET foo PROPERTY LINK_INTERFACE_LIBRARIES_DEBUG bar) is obvious, but what is not so obvious is that target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar) and target_link_libraries(foo LINK_PUBLIC bar) also populate that property and cause the old interface to be exported. That would be a mystery to someone who doesn't want to export the old interface anymore. Maybe we can deprecate those (and introduce a warning on export if the policy is NEW) and introduce target_link_libraries(foo INTERFACE bar) target_link_libraries(foo PRIVATE bar) target_link_libraries(foo PUBLIC bar) Not INTERFACE_LINK_LIBRARIES, because tll() will soon be doing more than just linking. The names could in theory conflict with existing libraries, but we could also handle that while parsing the args with the same policy or a new one. I would like to provide a way for people to not be setting the old properties at all anymore. Thoughts on that? Steve. -- 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 0013755]: find_package_handle_standard_args(XX DEFAULT_MSG XX_FOUND) always succeeds
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13755 == Reported By:Nick Hutchinson Assigned To: == Project:CMake Issue ID: 13755 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-29 11:20 NZDT Last Modified: 2012-11-29 11:20 NZDT == Summary:find_package_handle_standard_args(XX DEFAULT_MSG XX_FOUND) always succeeds Description: The following CMakeList.txt file always succeeds with --Found XX: TRUE. It ought not to; XX_FOUND has not been declared anywhere. I would expect find_package_handle_standard_args() to report that XX could not be found, and to set XX_FOUND to false. cmake_minimum_required(VERSION 2.8.8) include (FindPackageHandleStandardArgs) find_package_handle_standard_args(XX DEFAULT_MSG XX_FOUND) == Issue History Date ModifiedUsername FieldChange == 2012-11-29 11:20 Nick HutchinsonNew 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
[cmake-developers] [CMake 0013756]: Infinite loop when reconfiguring with different CMAKE_C_COMPILER
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13756 == Reported By:Nick Hutchinson Assigned To: == Project:CMake Issue ID: 13756 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-29 11:29 NZDT Last Modified: 2012-11-29 11:29 NZDT == Summary:Infinite loop when reconfiguring with different CMAKE_C_COMPILER Description: It's possible to get CMake stuck in a seemingly infinite loop when reconfiguring a project. Steps to Reproduce: 1. Create the following trivial CMakeList.txt: cmake_minimum_required(VERSION 2.8.8) 2. `cd` to the directory containing this file, and execute `cmake .` 3. Execute `cmake . -DCMAKE_C_COMPILER=cc` Expected Behaviour: CMake reconfigures the project with the specified compiler. Actual Behaviour: CMake prints the following to stdout in an infinite loop: -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_C_COMPILER= cc == Issue History Date ModifiedUsername FieldChange == 2012-11-29 11:29 Nick HutchinsonNew 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] General Config.cmake file issue on ArchLinux
On Saturday 17 November 2012, Alexander Neundorf wrote: Hi, maybe I am missing something, but here we go: on 64bit ArchLinux installations, /lib64/ is a symlink to /usr/lib/. /bin/ and /usr/bin/ are normal directories, no symlinks. Now if a Config.cmake files is installed into /usr/lib/foo/, and references other files of its installations using relative paths from its own location to e.g. /usr/bin/ (../../bin/ ), there is breakage. CMake finds FooConfig.cmake in /lib64/foo/FooConfig.cmake (which it seems to search before /usr/lib). Then it goes ../../bin/, but doesn't end up in /usr/bin/, where e.g. some executable is located, but instead it goes to /lib64/foo/../../bin/, which is /bin/, but the expected executable is not there, and so the FooConfig.cmake file fails. I'm not sure what the right way to deal with this is. Is this only on ArchLinux ? If so, maybe the best thing to do is to tell the ArchLinux developers to set up their symlinks in a different way ? Having e.g. /usr/lib64/ point to /usr/lib/ would make it work I think. Or if /lib64/ points to /usr/lib/, then maybe /bin/ should also point to /usr/bin/. Other ideas ? Or can CMake be tweaked to handle this ? How about this: cmake could check whether /lib64 is a symlink to /usr/lib, and if so, skip /lib64 ? This will break Config files installed to /lib64/cmake/, but I would assume Config.cmake files in /usr/lib/cmake/ are much more common than in /lib64/cmake/. 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] Problem with Visual Studio 2010, Windows 7 64bit
Interesting ... I have no problems, the only thing I can think of is that I had VS 2010 SP1 installed before I installed VS 2012 Express, I did not use any of the RC versions. Sent from an Android tablet. On 28/11/2012 6:51 PM, Petr Kmoch petr.km...@gmail.com wrote: Hi all, VS 2012 and VS 2010 installed together *can* actually cause problems (it certainly did for me). I was getting exactly the same error as David Doria, and I had to install a service pack for 2010 to overcome it. See e.g. http://social.msdn.microsoft.com/Forums/da-DK/vssetup/thread/d10adba0-e082-494a-bb16-2bfc039faa80or http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c Petr On Wed, Nov 28, 2012 at 4:12 AM, Andrew Maclean andrew.amacl...@gmail.com wrote: VS 2012 will not cause a problem I have both VS 2010 and VS2012 (both express) installed but am waiting for QT to be able to built for VS2012 before moving to VS2012 express. Regards Andrew -- Forwarded message -- From: David Doria daviddo...@gmail.com To: David Cole david.c...@kitware.com Cc: cmake Mailing List cmake@cmake.org Date: Tue, 27 Nov 2012 21:06:36 -0500 Subject: Re: [CMake] Problem with Visual Studio 2010, Windows 7 64bit On Tue, Nov 27, 2012 at 4:37 PM, David Cole david.c...@kitware.com wrote: Are you using an Express edition of VS without an SDK installed? If so, install an SDK and try again from a clean build directory. If not, we'll need more information. VS 2010 on Windows 7 works great for me, even for a VTK build tree... It was not VS Express, but just VS 2010. I also had VS 2012 installed, could that cause a problem? I uninstalled both and reinstalled 2010 and it works fine now. For future reference, what other information could I have provided? The CMakeCache.txt file? David -- ___ Andrew J. P. Maclean ___ -- 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
[CMake] Testing Qt 5 Beta 2 CMake files
Hi there, I emailed before about reviewing Config files that are being shipped with Qt 5 and got great feedback: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7165/focus=41551 Now that Qt 5 beta 2 is out, I'd like to ask for feedback again on anything that can still be changed before Qt 5.0. Note that Qt 5 beta 1 was broken regarding cmake files on Windows and Mac. As those are not primary platforms for me, I'd particularly appreciate feedback on those. You can download Qt 5 beta 2 here: http://qt-project.org/downloads Known issues are here: http://qt-project.org/wiki/Qt500beta2KnownIssues cmake related documentation is here: http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html unit tests are here: https://qt.gitorious.org/qt/qtbase/trees/master/tests/auto/cmake Thanks for any feedback! Steve. -- 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 Visual Studio 2010, Windows 7 64bit
On Wed, Nov 28, 2012 at 4:22 AM, Andrew Maclean andrew.amacl...@gmail.com wrote: Interesting ... I have no problems, the only thing I can think of is that I had VS 2010 SP1 installed before I installed VS 2012 Express, I did not use any of the RC versions. Petr, A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. It would really be great if there were better checks/errors because it is really a huge barrier for projects like VTK to get users to fight through install problems. Hey you should use VTK for that works when they have to follow a few instructions and it works, but when they have to spend days working through cryptic errors most tend to give up and then we lose a user. Andrew, I'm almost certain that it will never work using the VS generators (with very different can't find the compiler type of errors) unless you run cmake-gui from a terminal unless you have manually added many VS things to the system environment variables. At least that has been my experience on many machines. 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] how to add_library with an already compiled lib in a zip file ?
Hi,
I'm struggling with the following requirement:
I have a lib stored in a zip file (the lib is not built via cmake, e.g.
delivered from external company).
I want a target to link against this lib and want to extract the lib from the
zip file only if
this specific target is being built, and only if it is not already unzipped.
What I tried in the libs directory:
set(TARGET xxx)
add_library(${TARGET} STATIC IMPORTED GLOBAL)
set_target_properties(${TARGET} PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/xxx.a)
set(ZIPFILE xxx.zip)
add_custom_target(${TARGET}_lib
COMMAND unzip -o ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
)
add_dependencies(${TARGET} ${TARGET}_lib)
Then I can use this target in e.g.
target_link_libraries(myTarget xxx)
The above however unzips the lib every time, even if it is already existing.
Is it possible to avoid that ?
P.S:This is the simple example. I have other similar problems when the zip file
not only
holds 1 library but also a bunch of headerfiles and more than 1 lib ...
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
This mail was not scanned before sending.
It was sent from a secure Linux desktop.
--
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 Visual Studio 2010, Windows 7 64bit
On Nov 28, 2012, at 7:37 AM, David Doria daviddo...@gmail.com wrote: On Wed, Nov 28, 2012 at 4:22 AM, Andrew Maclean andrew.amacl...@gmail.com wrote: Interesting ... I have no problems, the only thing I can think of is that I had VS 2010 SP1 installed before I installed VS 2012 Express, I did not use any of the RC versions. Petr, A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. It would really be great if there were better checks/errors because it is really a huge barrier for projects like VTK to get users to fight through install problems. Hey you should use VTK for that works when they have to follow a few instructions and it works, but when they have to spend days working through cryptic errors most tend to give up and then we lose a user. Andrew, I'm almost certain that it will never work using the VS generators (with very different can't find the compiler type of errors) unless you run cmake-gui from a terminal unless you have manually added many VS things to the system environment variables. At least that has been my experience on many machines. David -- Here is my theory on mixing visual studios. When you install Visual Studio Windows will dutifully add the Visual Studio tools to the PATH for everyone. This is why you can just launch CMakeGui and have the Visual Studio generators work correctly. All is well. This is where I ran into problems.. Now install Visual Studio 2012 (or any other version) alonside VS2010 and Windows will again the 2012 to the PATH also. Now you have BOTH VS version's tools in the path but what ever is found FIRST is the one that is going to be used which will cause problems when launching CMakeGUi from Windows Explorer. At least this is what I saw years ago and why I NEVER mix versions. I install each version into its own Virtual Machine and run that way. It avoids all of these PATH issues. Unless CMake has some code to look into the registry to fully determine which compiler you want and setup the environment correctly by removing PATHS from a version of Visual Studio that you are NOT using I don't see how having more than a single Visual studio installed is going to work*** *** It can work if you go into the Environment Variables for Windows and REMOVE any and all references to Visual Studio. Then when you want to configure a project you launch a Visual Studio Command Prompt or Visual Studio x64 Command Prompt and then launch CMake-gui from there which will properly setup the environment for you and the generator will work correctly every time because there is no mixing of paths. This is how I do it. Yes it is a few extra clicks and some typing but it avoids days of fighting hidden path issues. Of course I could be wrong on most of the above but it works for me for the last 3 years so I am not about to change. Just my nickels worth of advice. ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- 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 Visual Studio 2010, Windows 7 64bit
Am 28.11.2012 13:59, schrieb Michael Jackson: On Nov 28, 2012, at 7:37 AM, David Doria daviddo...@gmail.com wrote: On Wed, Nov 28, 2012 at 4:22 AM, Andrew Maclean andrew.amacl...@gmail.com wrote: Interesting ... I have no problems, the only thing I can think of is that I had VS 2010 SP1 installed before I installed VS 2012 Express, I did not use any of the RC versions. Petr, A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. It would really be great if there were better checks/errors because it is really a huge barrier for projects like VTK to get users to fight through install problems. Hey you should use VTK for that works when they have to follow a few instructions and it works, but when they have to spend days working through cryptic errors most tend to give up and then we lose a user. Andrew, I'm almost certain that it will never work using the VS generators (with very different can't find the compiler type of errors) unless you run cmake-gui from a terminal unless you have manually added many VS things to the system environment variables. At least that has been my experience on many machines. David -- Here is my theory on mixing visual studios. When you install Visual Studio Windows will dutifully add the Visual Studio tools to the PATH for everyone. This is why you can just launch CMakeGui and have the Visual Studio generators work correctly. All is well. This is where I ran into problems.. Now install Visual Studio 2012 (or any other version) alonside VS2010 and Windows will again the 2012 to the PATH also. Now you have BOTH VS version's tools in the path but what ever is found FIRST is the one that is going to be used which will cause problems when launching CMakeGUi from Windows Explorer. At least this is what I saw years ago and why I NEVER mix versions. I install each version into its own Virtual Machine and run that way. It avoids all of these PATH issues. Unless CMake has some code to look into the registry to fully determine which compiler you want and setup the environment correctly by removing PATHS from a version of Visual Studio that you are NOT using I don't see how having more than a single Visual studio installed is going to work*** I doubt your theory ;-) VS installer does not insert VS tools into the PATH. That's one reason why you have the vsvars-batch files to set up the environment. Another source of my doubt is that I also can confirm that the problems with VS 2010 vanished after installing VS2010 SP1. Regards Titus -- 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 Visual Studio 2010, Windows 7 64bit
You should never allow Visual Studio or CMake installers to make changes to your environment. They are unnecessary and cause complications when multiple versions are installed. When I use cmake-gui, I double-click an icon on my desktop, or start it from an icon in the start menu. I almost never run it from a Visual Studio command prompt. It's unnecessary... Visual Studio knows all about its own installation and environment, and so there's no need to allow it to modify your machine's environment. That's what the command prompt shortcuts are for: when you need the environment, you can just run the command prompt with it, and use it as needed. But for typical VS only use, it's never needed. So: moral of the story from my point of view is: minimize environment changes from all installers... Things should work without environment changes, and if they don't... that's a bug. 2 cents, David C. On Wed, Nov 28, 2012 at 7:59 AM, Michael Jackson mike.jack...@bluequartz.net wrote: On Nov 28, 2012, at 7:37 AM, David Doria daviddo...@gmail.com wrote: On Wed, Nov 28, 2012 at 4:22 AM, Andrew Maclean andrew.amacl...@gmail.com wrote: Interesting ... I have no problems, the only thing I can think of is that I had VS 2010 SP1 installed before I installed VS 2012 Express, I did not use any of the RC versions. Petr, A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. It would really be great if there were better checks/errors because it is really a huge barrier for projects like VTK to get users to fight through install problems. Hey you should use VTK for that works when they have to follow a few instructions and it works, but when they have to spend days working through cryptic errors most tend to give up and then we lose a user. Andrew, I'm almost certain that it will never work using the VS generators (with very different can't find the compiler type of errors) unless you run cmake-gui from a terminal unless you have manually added many VS things to the system environment variables. At least that has been my experience on many machines. David -- Here is my theory on mixing visual studios. When you install Visual Studio Windows will dutifully add the Visual Studio tools to the PATH for everyone. This is why you can just launch CMakeGui and have the Visual Studio generators work correctly. All is well. This is where I ran into problems.. Now install Visual Studio 2012 (or any other version) alonside VS2010 and Windows will again the 2012 to the PATH also. Now you have BOTH VS version's tools in the path but what ever is found FIRST is the one that is going to be used which will cause problems when launching CMakeGUi from Windows Explorer. At least this is what I saw years ago and why I NEVER mix versions. I install each version into its own Virtual Machine and run that way. It avoids all of these PATH issues. Unless CMake has some code to look into the registry to fully determine which compiler you want and setup the environment correctly by removing PATHS from a version of Visual Studio that you are NOT using I don't see how having more than a single Visual studio installed is going to work*** *** It can work if you go into the Environment Variables for Windows and REMOVE any and all references to Visual Studio. Then when you want to configure a project you launch a Visual Studio Command Prompt or Visual Studio x64 Command Prompt and then launch CMake-gui from there which will properly setup the environment for you and the generator will work correctly every time because there is no mixing of paths. This is how I do it. Yes it is a few extra clicks and some typing but it avoids days of fighting hidden path issues. Of course I could be wrong on most of the above but it works for me for the last 3 years so I am not about to change. Just my nickels worth of advice. ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- 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] how to add_library with an already compiled lib in a zip file ?
Hi,
On Wed, Nov 28, 2012 at 1:41 PM, Martin Koller martin.kol...@etm.at wrote:
Hi,
I'm struggling with the following requirement:
I have a lib stored in a zip file (the lib is not built via cmake, e.g.
delivered from external company).
I want a target to link against this lib and want to extract the lib from the
zip file only if
this specific target is being built, and only if it is not already unzipped.
What I tried in the libs directory:
set(TARGET xxx)
add_library(${TARGET} STATIC IMPORTED GLOBAL)
set_target_properties(${TARGET} PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/xxx.a)
set(ZIPFILE xxx.zip)
add_custom_target(${TARGET}_lib
COMMAND unzip -o ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
)
add_dependencies(${TARGET} ${TARGET}_lib)
Then I can use this target in e.g.
target_link_libraries(myTarget xxx)
The above however unzips the lib every time, even if it is already existing.
Is it possible to avoid that ?
This should be doable by splitting the custom target into a custom
command and a custom target. For the custom command you then need to
list the output files generated by the unzip and thus it'll only be
executed if the .zip is newer than the output files or an output file
is missing. The custom target is then used to provide a dummy target
(use echo or something like that as command) and depends on the output
files from the custom command and used with add_dependencies. That way
the custom-target will always be out-of-date and hence built but it
only depends on the output of the custom-command which in turn knows
when to re-run the command and thus only does this if necessary.
Another option would be to do this in a cmake script file manually and
run that via cmake -P as command.
Andreas
--
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] how to add_library with an already compiled lib in a zip file ?
Hi Martin,
you have to add a custom command to generate your lib and make your custom
target depending on it:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/xxx.a
COMMAND
unzip -o ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
)
add_custom_target(
${TARGET}_lib
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/xxx.a
)
This will unzip the xxx.a only if your zipfile has changed.
Regards, Kiwi
On 28.11.2012 13:41, Martin Koller wrote:
Hi,
I'm struggling with the following requirement:
I have a lib stored in a zip file (the lib is not built via cmake, e.g.
delivered from external company).
I want a target to link against this lib and want to extract the lib from the
zip file only if
this specific target is being built, and only if it is not already unzipped.
What I tried in the libs directory:
set(TARGET xxx)
add_library(${TARGET} STATIC IMPORTED GLOBAL)
set_target_properties(${TARGET} PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/xxx.a)
set(ZIPFILE xxx.zip)
add_custom_target(${TARGET}_lib
COMMAND unzip -o ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${ZIPFILE}
)
add_dependencies(${TARGET} ${TARGET}_lib)
Then I can use this target in e.g.
target_link_libraries(myTarget xxx)
The above however unzips the lib every time, even if it is already existing.
Is it possible to avoid that ?
P.S:This is the simple example. I have other similar problems when the zip file
not only
holds 1 library but also a bunch of headerfiles and more than 1 lib ...
--
Kay-Uwe (Kiwi) Lorenz
IT Department
ModuleWorks GmbH
Ritterstr. 12a
52072 Aachen
Germany
HRB 11871
Amtsgericht Aachen
Geschäftsführer Yavuz Murtezaoglu
--
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] Testing Qt 5 Beta 2 CMake files
I emailed before about reviewing Config files that are being shipped with Qt 5 and got great feedback: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7165/focus=41551 Now that Qt 5 beta 2 is out, I'd like to ask for feedback again on anything that can still be changed before Qt 5.0. Note that Qt 5 beta 1 was broken regarding cmake files on Windows and Mac. As those are not primary platforms for me, I'd particularly appreciate feedback on those. You can download Qt 5 beta 2 here: http://qt-project.org/downloads Known issues are here: http://qt-project.org/wiki/Qt500beta2KnownIssues cmake related documentation is here: http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html unit tests are here: https://qt.gitorious.org/qt/qtbase/trees/master/tests/auto/cmake Thanks for any feedback! I will try to take a look at this on a windows 7 x64 test box when I can. John -- 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 Visual Studio 2010, Windows 7 64bit
A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. I also remember that Visual Studio 2012 RTM had an optimizer bug that caused Qt applications to crash so the first thing I always do after installing VS 2010 is install SP1. John -- 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 Visual Studio 2010, Windows 7 64bit
On Wed, Nov 28, 2012 at 9:14 AM, John Drescher dresche...@gmail.com wrote: A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. I also remember that Visual Studio 2012 RTM had an optimizer bug that caused Qt applications to crash so the first thing I always do after installing VS 2010 is install SP1. John Is there a way to have CMake detect this sort of thing and say It is not working, and it looks like it is because you are using VS2010 without SP1.? These are the kinds of errors that users don't mind seeing as much. The error that I posted in the first email of this thread means nothing to the average user and causes major headaches. Also, I don't think it should depend on the user having installed VS with any particular environment settings - the typical case I run into is someone who already is perfectly happy with their VS setup that I tell to use CMake to do something. They then run into these problems and shouldn't have to reinstall it just to use CMake. Perhaps a guide to how to setup your environment so that VS still works as usual but CMake is also happy would be a nice addition, or even a button in CMake somewhere to Setup the environment to allow VS to be found properly. Linux users are annoyed but often know what to do when you ask them to manipulate environment variables, but in my experience Windows users (of course not Windows open source devs, but typical Windows users) don't even know where to go to change environment variables, so asking them to get them right manually doesn't seem like a good plan. 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
Re: [CMake] Link flags not applied to static library
Hi,
I set this:
set (STATIC_LIBRARY_FLAGS_RELWITHDEBINFO
${STATIC_LIBRARY_FLAGS_RELWITHDEBINFO} /LTCG)
and it didn't seem to work. MSVC still has no LTCG flag set for any of my
static libraries.
does this feature work?
cheers,
Paul
On 23 June 2011 01:02, Ben Medina ben.med...@gmail.com wrote:
So that the answer stays on the list:
One must use the STATIC_LIBRARY_FLAGS property, rather than
LINK_FLAGS, for static libraries.
On Tue, Jun 21, 2011 at 3:12 PM, Ben Medina ben.med...@gmail.com wrote:
Since I got no feedback, I assume it's a bug. I've filed it here:
0012295: LINK_FLAGS_RELEASE has no effect on static libraries for MSVC
generators
http://www.cmake.org/Bug/view.php?id=12295
On Mon, Jun 13, 2011 at 11:50 AM, Ben Medina ben.med...@gmail.com
wrote:
Hello all,
I'm using CMake 2.8.4 and am seeing an odd differenc between static
and shared libraries in regard to the LINK_FLAGS property. In
particular, I'm enabling Whole program optimization in Visual Studio
2010, which is done by add /GL as a compiler flag and /LTCG as a
linker flag for the release configuration. However, the link flag is
not used for static libraries, leading to a build warning about
compiling with /GL but linking without /LTCG.
Here's an example:
cmake_minimum_required (VERSION 2.8)
project (link_test)
set (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /GL)
add_library (static_test STATIC a.cpp)
set_target_properties (
static_test
PROPERTIES
LINK_FLAGS_RELEASE /LTCG
)
add_library (shared_test SHARED a.cpp)
set_target_properties (
shared_test
PROPERTIES
LINK_FLAGS_RELEASE /LTCG
)
Just add an empty file called a.cpp to the directory, then build the
whole project in release configuration. You'll get a warning like this
for the static_test library:
2 a.obj : MSIL .netmodule or module compiled with /GL found;
restarting link with /LTCG; add /LTCG to the link command line to
improve
Why is CMake not applying LINK_FLAGS_RELEASE to the static library?
Thanks,
Ben
___
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] CMake 2.8.10 with Xcode 4.4.1
I can't for the life of me reproduce this. I've tried on my own Mac with Xcode 4.2, and on a colleague's Mac with Xcode 4.5.2. I can't seem to find a 4.4.1 machine to try this out on... Is this a problem for anybody else using CMake 2.8.10 on a Mac with the Xcode generator? Can you send the full output of the configure step (in a clean build directory)? Also, the output of running find CMakeFiles after the configure is done? (What files exist in CMakeFiles after a fresh configure...?) The file that's missing should be generated during the first configure. cd /Users/nicholas/temp/xcode find CMakeFiles Very mysterious. On Thu, Nov 22, 2012 at 1:08 AM, Nicholas Yue yue.nicho...@gmail.comwrote: On 19/11/12 10:31 PM, David Cole wrote: In the CMake source tree, can you try to build Tests/Tutorial/Step1 with the Xcode generator and report the results? $ xcodebuild Tutorial.xcodeproj === BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Tutorial WITH THE DEFAULT CONFIGURATION (Debug) === Check dependencies unsupported build action 'Tutorial.xcodeproj' ** BUILD FAILED ** The following build commands failed: Check dependencies (1 failure) Can you send your simple CMakeLists.txt file and its single source here? Files are attached What does your machine report when you run xcode-select -print-path? $ xcode-select -print-path /Applications/Xcode.app/**Contents/Developer Cheers -- Nicholas Yue Graphics - RenderMan, Visualization, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/**nicholasyuehttp://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/**naiadtoolshttps://vimeo.com/channels/naiadtools -- 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] (no subject)
I have a problem where I have a build that depends on the output from another build. If I pass cmake the value of the libraries I want to link against, I can see the libraries through my find script without a problem using the find_library command.My problem is that I don't want to make the user always tell me the name of the library before I can do the compile since I am looking to automate the final build. My first build creates a directory build -- 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] Find a library that matches a specific pattern
I have a build that depends on the output from another build. We can't
combine the code into one build due to other issues.
I need to get cmake to pass the values of the libraries I want to link
against. I have worked out a find script for my second build that
allows me to use the find_library command to pull the .lib file that I'm
looking for.However, I must force the user to specify the specific name
of the library and I need to avoid this and just be able to pick up the
value if the name passes validation and the version is any number since
ultimately this whole process will be automated and I don't want to have to
worry about specifying version numbers.
My first build creates a directory
- build
- win64
- VC10
- bin
- Release
- filea1231.1.1.1.lib
- fileb2341.1.1.1.lib
- filec3451.1.1.1.lib
For the second build I force the user to tell me the path of the build
directory (i.e. C:\build\win64\VC10\bin\Release and assign this to a value
of first_build_dir)
I then have a find script where I am trying to find the library (i.e.
filea1231.1.1.1)
set (file_name filea1231.1.1.1)
find_library(my_library
name ${file_name}
PATHS ${first_build_dir}
)
The problem I have is that the filea1231.1.1.1 might change for the next
build (i.e filea1231.1.1.2).There is only one file named filea so I'd
like to be able to search for filea*.lib no matter what the versioning
information contains.
I thought I needed to go down the path of using a string(regex
match([filea0-9]+\\.[0-9]\\.[0-9]\\.[0-9] file_name) however I can't figure
out how to make this work in my current situation.
I then went down the path of trying the file(strings filea*.lib
file_name) option but it returned my ${first_build_dir} path
I'm looking for suggestions on how to handle pulling the changing file name
within cmake for use at anytime.
Thanks
--
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] can CMake determine linker version ?
Dear experts,
in recent versions of ld-linker I have to use this flags for static linking:
target_link_libraries(${EXECUTABLE} -Wl,--no-export-dynamic)
however, older versions, like GNU ld version 2.17.50.0.6-20.el5 20061020 does
not know the flag --no-export-dynamic.
Would it be please possible to get version of the linker and determine
accordingly which flags to use ?
Best, Miro
--
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] Find a library that matches a specific pattern
You can use file(GLOB variable [RELATIVE path] [globbing expression] ...)
file( GLOB result ${first_build_dir} filea*.lib)
Result will contain a list of files that match the globbing expression.
Enjoy!
Keith
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
katie outram
Sent: Wednesday, November 28, 2012 2:37 PM
To: cmake@cmake.org
Subject: [CMake] Find a library that matches a specific pattern
I have a build that depends on the output from another build. We can't
combine the code into one build due to other issues.
I need to get cmake to pass the values of the libraries I want to link against.
I have worked out a find script for my second build that allows me to use
the find_library command to pull the .lib file that I'm looking for.
However, I must force the user to specify the specific name of the library and
I need to avoid this and just be able to pick up the value if the name passes
validation and the version is any number since ultimately this whole process
will be automated and I don't want to have to worry about specifying version
numbers.
My first build creates a directory
* build
* win64
* VC10
* bin
* Release
* filea1231.1.1.1.lib
* fileb2341.1.1.1.lib
* filec3451.1.1.1.lib
For the second build I force the user to tell me the path of the build
directory (i.e. C:\build\win64\VC10\bin\Release and assign this to a value of
first_build_dir)
I then have a find script where I am trying to find the library (i.e.
filea1231.1.1.1)
set (file_name filea1231.1.1.1)
find_library(my_library
name ${file_name}
PATHS ${first_build_dir}
)
The problem I have is that the filea1231.1.1.1 might change for the next build
(i.e filea1231.1.1.2).There is only one file named filea so I'd like to be
able to search for filea*.lib no matter what the versioning information
contains.
I thought I needed to go down the path of using a string(regex
match([filea0-9]+\\.[0-9]\\.[0-9]\\.[0-9file:///\\.[0-9]\.%5b0-9] file_name)
however I can't figure out how to make this work in my current situation.
I then went down the path of trying the file(strings filea*.lib file_name)
option but it returned my ${first_build_dir} path
I'm looking for suggestions on how to handle pulling the changing file name
within cmake for use at anytime.
Thanks
--
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] Find a library that matches a specific pattern
Have the first build generate a *.cmake file with all the libraries and their
absolute paths listed in it. Then the second build simply looks for and reads
that file to get the proper information about the libraries.
--
Mike Jackson www.bluequartz.net
On Nov 28, 2012, at 3:36 PM, katie outram wrote:
I have a build that depends on the output from another build. We can't
combine the code into one build due to other issues.
I need to get cmake to pass the values of the libraries I want to link
against. I have worked out a find script for my second build that allows
me to use the find_library command to pull the .lib file that I'm looking
for.However, I must force the user to specify the specific name of the
library and I need to avoid this and just be able to pick up the value if the
name passes validation and the version is any number since ultimately this
whole process will be automated and I don't want to have to worry about
specifying version numbers.
My first build creates a directory
• build
• win64
• VC10
• bin
• Release
• filea1231.1.1.1.lib
• fileb2341.1.1.1.lib
• filec3451.1.1.1.lib
For the second build I force the user to tell me the path of the build
directory (i.e. C:\build\win64\VC10\bin\Release and assign this to a value of
first_build_dir)
I then have a find script where I am trying to find the library (i.e.
filea1231.1.1.1)
set (file_name filea1231.1.1.1)
find_library(my_library
name ${file_name}
PATHS ${first_build_dir}
)
The problem I have is that the filea1231.1.1.1 might change for the next
build (i.e filea1231.1.1.2).There is only one file named filea so I'd
like to be able to search for filea*.lib no matter what the versioning
information contains.
I thought I needed to go down the path of using a string(regex
match([filea0-9]+\\.[0-9]\\.[0-9]\\.[0-9] file_name) however I can't figure
out how to make this work in my current situation.
I then went down the path of trying the file(strings filea*.lib file_name)
option but it returned my ${first_build_dir} path
I'm looking for suggestions on how to handle pulling the changing file name
within cmake for use at anytime.
Thanks
--
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 Visual Studio 2010, Windows 7 64bit
Hi David, I agree with what you are saying. Just to confirm it I built a series of programs (67 in the solution) that use boost (by using CMake as you describe below) for Visual Studio Express 2010 and 2012 (both 64-bit builds). CMake had no trouble finding the relevant build environment for VS2010 and VS2012. This confirms that CMake works as expected and also there is no need to modify the build environment when using the IDE. However if you build from a command line using devenv, msbuild or nmake then you will need to set the appropriate environment for VS2010 or VS2012 but I would do this after running the cmake-gui by double-clicking on the icon as David mentions below. Let CMake set up everything first and then if you want to use a command prompt, use the relevant VS batch file to set up the environment in the command window. By the way I think the VS2012 compile is faster then the VS2010 compile, in the above case 45s vs 51s. Regards Andrew -- Forwarded message -- From: David Cole david.c...@kitware.com To: Michael Jackson mike.jack...@bluequartz.net Cc: cmake@cmake.org MailingList cmake@cmake.org Date: Wed, 28 Nov 2012 08:17:24 -0500 Subject: Re: [CMake] Problem with Visual Studio 2010, Windows 7 64bit You should never allow Visual Studio or CMake installers to make changes to your environment. They are unnecessary and cause complications when multiple versions are installed. When I use cmake-gui, I double-click an icon on my desktop, or start it from an icon in the start menu. I almost never run it from a Visual Studio command prompt. It's unnecessary... Visual Studio knows all about its own installation and environment, and so there's no need to allow it to modify your machine's environment. That's what the command prompt shortcuts are for: when you need the environment, you can just run the command prompt with it, and use it as needed. But for typical VS only use, it's never needed. So: moral of the story from my point of view is: minimize environment changes from all installers... Things should work without environment changes, and if they don't... that's a bug. 2 cents, David C. On Wed, Nov 28, 2012 at 7:59 AM, Michael Jackson mike.jack...@bluequartz.net wrote: On Nov 28, 2012, at 7:37 AM, David Doria daviddo...@gmail.com wrote: On Wed, Nov 28, 2012 at 4:22 AM, Andrew Maclean andrew.amacl...@gmail.com wrote: Interesting ... I have no problems, the only thing I can think of is that I had VS 2010 SP1 installed before I installed VS 2012 Express, I did not use any of the RC versions. Petr, A colleague mentioned that with the same setup he was getting the same error, and then installed SP1 for VS 2010 and things started working. It would really be great if there were better checks/errors because it is really a huge barrier for projects like VTK to get users to fight through install problems. Hey you should use VTK for that works when they have to follow a few instructions and it works, but when they have to spend days working through cryptic errors most tend to give up and then we lose a user. Andrew, I'm almost certain that it will never work using the VS generators (with very different can't find the compiler type of errors) unless you run cmake-gui from a terminal unless you have manually added many VS things to the system environment variables. At least that has been my experience on many machines. David -- Here is my theory on mixing visual studios. When you install Visual Studio Windows will dutifully add the Visual Studio tools to the PATH for everyone. This is why you can just launch CMakeGui and have the Visual Studio generators work correctly. All is well. This is where I ran into problems.. Now install Visual Studio 2012 (or any other version) alonside VS2010 and Windows will again the 2012 to the PATH also. Now you have BOTH VS version's tools in the path but what ever is found FIRST is the one that is going to be used which will cause problems when launching CMakeGUi from Windows Explorer. At least this is what I saw years ago and why I NEVER mix versions. I install each version into its own Virtual Machine and run that way. It avoids all of these PATH issues. Unless CMake has some code to look into the registry to fully determine which compiler you want and setup the environment correctly by removing PATHS from a version of Visual Studio that you are NOT using I don't see how having more than a single Visual studio installed is going to work*** *** It can work if you go into the Environment Variables for Windows and REMOVE any and all references to Visual Studio. Then when you want to configure a project you launch a Visual Studio Command Prompt or Visual Studio x64 Command Prompt and then launch CMake-gui from there which will properly setup the environment for you and the generator will work correctly every time because
[CMake] using find_package from within toolchain file
Hello,
I am attempting to use find_package within each toolchain file in
combination with cross-compiling WebKit. The locations in which both
WebKit and BuildRoot are situated on the Debian Linux systems are not
standardized, but up to individual developers. The version of CMake is
2.8.7.
WebKit's build procedure is invoked as so:
Tools/Scripts/build-webkit --customportname --crosscompiletarget=xyz
The first time through, CMAKE_SOURCE_DIR is equal to the root of the
git repository in which a developer has WebKit checked out into (for
example, /webkitroot). The created toolchain files themselves are
located in ${CMAKE_SOURCE_DIR}/Source/cmake, which is where WebKit
keeps its other .cmake files, as is the FindBuildRoot.cmake file for
finding the BuildRoot package. Everything is found, just as one might
expect.
However, immediately afterward, the toolchain file is automatically
invoked again, this time with
CMAKE_SOURCE_DIR=/webkitroot/WebKitBuild/Debug/CMakeFiles/CMakeTmp. An
attempt to establish the CMAKE_MODULE_PATH this time around by tacking
on Source/cmake to the end of this path fails miserably, of course, so
BuildRoot is not found, and the build fails to complete.
I am unsure if the reinvocation usually occurs with CMake, or whether
this is a peculiarity of WebKit's compilation procedure. There are a
few different potential solutions I could attempt, but I thought I
should seek advice re: the approaches that would be considered to be
best practices by the CMake community.
Thanks,
Dave
--
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] How to check for a symbol that requires two header files in CMake?
Hi all, I am trying to find out whether getifaddrs function is avialable. To get symbol getifaddrs defined you have to include both sys/types.h and ifaddrs.h. Here's the synopsis of the function from the man page: #include sys/types.h #include ifaddrs.h int getifaddrs(struct ifaddrs **ifap); When checking whether the symbol exists, I've tried the following: set (CMAKE_EXTRA_INCLUDE_FILES sys/types.h) check_symbol_exists (getifaddrs ifaddrs.h SP_HAVE_IFADDRS) set (CMAKE_EXTRA_INCLUDE_FILES) However, the generated test program still includes only ifaddrs.h and thus fails to detect the symbol. How can I force it to include sys/types.h as well? Martin -- 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] How to check for a symbol that requires two header files in CMake?
2012/11/29 Martin Sustrik sust...@250bpm.com Hi all, I am trying to find out whether getifaddrs function is avialable. To get symbol getifaddrs defined you have to include both sys/types.h and ifaddrs.h. Here's the synopsis of the function from the man page: #include sys/types.h #include ifaddrs.h int getifaddrs(struct ifaddrs **ifap); When checking whether the symbol exists, I've tried the following: set (CMAKE_EXTRA_INCLUDE_FILES sys/types.h) check_symbol_exists (getifaddrs ifaddrs.h SP_HAVE_IFADDRS) set (CMAKE_EXTRA_INCLUDE_FILES) However, the generated test program still includes only ifaddrs.h and thus fails to detect the symbol. How can I force it to include sys/types.h as well? Martin -- Have you tried as per documentation provide list of files? check_symbol_exists (getifaddrs sys/types.h;ifaddrs.h SP_HAVE_IFADDRS) and don't forget this only for C. -- Best Regards, Sergei Nikulov -- 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, master, updated. v2.8.10.2-241-g581b0c0
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, master has been updated via 581b0c0d078b5f07f68a53b118f44fc6e8313601 (commit) via 3a1006e41fd7be22c415d1de45364f0c8ff4b697 (commit) via 40c36c9f7bd101185b06ddf2aee079ccbe7634d3 (commit) via 038df9e49e6fcb54d6f6a1bcfb09f6a0e5ec0c2e (commit) via 6fe4fcba787e4e27a4863faa28aa41ae11026d6b (commit) via 2118a2016f69f3c7cdb711eaaa2f6ca9374103ce (commit) via 6920fed652339ca6b45d98769c88a8c341e507b8 (commit) via 102521b6b3172e32b2985c53eadc6eaebe90245d (commit) via 332dc09d0de3b427eac8a36c3b0c1339daf7179c (commit) via d41d4d3d61275414958831bc3d5a45f74b1f2339 (commit) via 14861f88d2e33edc53ab00f92dfaaf860f9d4084 (commit) from 1ed04648519f8dad60dbe6c1b3952429a011eb4b (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=581b0c0d078b5f07f68a53b118f44fc6e8313601 commit 581b0c0d078b5f07f68a53b118f44fc6e8313601 Merge: 1ed0464 3a1006e Author: Brad King brad.k...@kitware.com AuthorDate: Wed Nov 28 08:49:56 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Nov 28 08:49:56 2012 -0500 Merge topic 'windows-ce' 3a1006e VS: Added Deploy at project configuration for WindowsCE targets 40c36c9 VS: Make DetermineCompilerId working with WinCE too 038df9e VS: Allow setting the name of the target platform 6fe4fcb VS: Add parser for WCE.VCPlatform.config to read WinCE platforms 2118a20 VS: Support setting correct subsystem and entry point for WinCE 6920fed VS: Change variable type of Name from const char* to string 102521b VS: Change variable type of ArchitectureId from const char* to string 332dc09 VS: Add static method to get the base of the registry d41d4d3 VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefile 14861f8 VS: Remove TargetMachine for linker when checking compiler id --- Summary of changes: Modules/CMakeCCompilerId.c.in |4 + Modules/CMakeCXXCompilerId.cpp.in |4 + Modules/CMakeDetermineCompilerId.cmake | 19 ++-- Modules/CMakeDetermineSystem.cmake |6 + Modules/CompilerId/VS-7.vcproj.in |3 +- Source/CMakeLists.txt |2 + Source/cmGlobalVisualStudio10Generator.cxx |3 +- Source/cmGlobalVisualStudio71Generator.cxx |2 +- Source/cmGlobalVisualStudio71Generator.h |2 +- Source/cmGlobalVisualStudio7Generator.cxx |6 +- Source/cmGlobalVisualStudio7Generator.h|2 +- Source/cmGlobalVisualStudio8Generator.cxx | 88 +++--- Source/cmGlobalVisualStudio8Generator.h| 15 +++- Source/cmGlobalVisualStudio9Generator.cxx | 64 ++--- Source/cmGlobalVisualStudio9Generator.h|1 + Source/cmGlobalVisualStudioGenerator.cxx | 15 ++- Source/cmGlobalVisualStudioGenerator.h |8 ++- Source/cmLocalVisualStudio7Generator.cxx | 20 - Source/cmLocalVisualStudio7Generator.h |1 + Source/cmVisualStudioWCEPlatformParser.cxx | 139 Source/cmVisualStudioWCEPlatformParser.h | 55 +++ 21 files changed, 402 insertions(+), 57 deletions(-) create mode 100644 Source/cmVisualStudioWCEPlatformParser.cxx create mode 100644 Source/cmVisualStudioWCEPlatformParser.h 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.10.2-1107-gdabf743
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 dabf7435a43085960a570ea746a65198630a467a (commit) via 581b0c0d078b5f07f68a53b118f44fc6e8313601 (commit) via 1ed04648519f8dad60dbe6c1b3952429a011eb4b (commit) from 6692827ddf62611acf96feb896c3a8ac00f5c7a8 (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=dabf7435a43085960a570ea746a65198630a467a commit dabf7435a43085960a570ea746a65198630a467a Merge: 6692827 581b0c0 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Nov 28 08:50:11 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Nov 28 08:50:11 2012 -0500 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 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
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1109-g8fc1a2c
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 8fc1a2c2c412ea5a75e0bffc353f25c20f2b829a (commit)
via 223850576b070f66a5eec5340b7eefa8ecf7b5de (commit)
from dabf7435a43085960a570ea746a65198630a467a (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=8fc1a2c2c412ea5a75e0bffc353f25c20f2b829a
commit 8fc1a2c2c412ea5a75e0bffc353f25c20f2b829a
Merge: dabf743 2238505
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Nov 28 12:13:39 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Nov 28 12:13:39 2012 -0500
Merge topic 'fix-watcom-test-timeout' into next
2238505 Watcom: Avoid prompt from wmake about dll with no exports...
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=223850576b070f66a5eec5340b7eefa8ecf7b5de
commit 223850576b070f66a5eec5340b7eefa8ecf7b5de
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Nov 28 12:11:52 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Nov 28 12:11:52 2012 -0500
Watcom: Avoid prompt from wmake about dll with no exports...
...by simply building a STATIC lib for the test, instead of a
SHARED one. Fixes test timeout on the Watcom dashboards.
diff --git a/Tests/EmptyDepends/CMakeLists.txt
b/Tests/EmptyDepends/CMakeLists.txt
index a24382c..832d9dc 100644
--- a/Tests/EmptyDepends/CMakeLists.txt
+++ b/Tests/EmptyDepends/CMakeLists.txt
@@ -12,4 +12,4 @@ add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/qrc_my.cxx
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/my.qrc
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/my.qrc)
-add_library(qrc SHARED ${CMAKE_BINARY_DIR}/qrc_my.cxx)
+add_library(qrc STATIC ${CMAKE_BINARY_DIR}/qrc_my.cxx)
---
Summary of changes:
Tests/EmptyDepends/CMakeLists.txt |2 +-
1 files changed, 1 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
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-242-gd5ac791
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, master has been updated via d5ac791366595be307896e9894c66815c1e1eb2f (commit) from 581b0c0d078b5f07f68a53b118f44fc6e8313601 (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=d5ac791366595be307896e9894c66815c1e1eb2f commit d5ac791366595be307896e9894c66815c1e1eb2f Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Nov 29 00:01:01 2012 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Nov 29 00:01:01 2012 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index a7afa52..824de7e 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20121128) +set(CMake_VERSION_TWEAK 20121129) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 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
