Re: [cmake-developers] Compiler features/extensions remaining/future issues
Brad King wrote: On 06/13/2014 05:19 AM, Stephen Kelly wrote: 11) WriteCompilerDetectionHeader vs GenerateExportHeader IMO these two modules are solving orthogonal problems and should not be mixed. I'm not sure I agree. GenerateExportHeader needs to know about deprecation in order to generate FOO_EXPORT_DEPRECATED and similar macros. So, they're not fully orthogonal. 12) Platform-specific defines Plenty of libraries already provide things like this. Not everyone agrees what UNIX or even Linux means. I was hesitant to accept WriteCompilerDetectionHeader in the first place because I never wanted to get in the business of providing a C++ SDK. It is reasonable to re-use all the C++ compiler version and feature info we already have, but I don't think we should provide more. Sounds good. Anyone wanting more can be pointed to boost::predef. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] How to query the SYSTEM flag for directory property INCLUDE_DIRECTORIES
Hello, while working on -isystem support for cotire I did not find a way to query the SYSTEM flag on the INCLUDE_DIRECTORIES directory property. Did I miss something or was this omitted intentionally? Thanks, Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Cygwin drive paths are killing me
Why are you holding back so much from giving us your real opinion of Cygwin? :-) Sorry about that, I'll have to try harder ;-) Seriously though, I wonder if some of your complaints have an answer. I'm sure they do. Also, I think it is important for Windows users to have access to Unix distributions (plural) of free software, where Unix refers to containing all the core command-line Unix tools that Unix developers know and love, and distribution is defined as a substantial body of software beyond those core tools that is built with a consistent set of (Unix) build tools. Thanks to Virtual Box (and others like it), they do have such access. Windows users can install any Linux distribution they want into a VM on top of Windows... The thing I will never understand is people's refusal to learn how to use the tools at their disposal. If you're on Windows, learn how to use the tools that work on Windows. Don't be all crippled without your usual toolset: learn something new! If you accept that premise... I don't. I completely disagree. Windows is Windows. If you don't like it, don't use it. ... then Cygwin is a really important example of such a Unix distribution, and the only other competitors for it that I am aware of at the present moment on Windows platforms are (1) MinGW+MSYS (a much simplified fork of an ancient Cygwin version) and (2) MinGW_w64+MSYS2 (a much simplified fork of modern Cygwin). I have msys Git installed, and in its bash prompt, I have every Unix-y tool I ever use on Windows. Mostly just grep really. And I wouldn't even have that installed except for requiring access to git repos. My opinion is that MinGW+MSYS days are numbered because MinGW_w64+MSYS2 reportedly fixes bugs much quicker... But isn't MSYS2 really the evolution of MSYS? (i.e. shouldn't MSYS days be numbered if there's an MSYS2? CMake 2.8's days are numbered as well, now that CMake 3 is out...) And really, aren't Windows's days numbered anyhow? The writing's on the wall. PC's will only be necessary for developers and high-volume data crunchers in another decade. Dave, I well understand that since you have had trouble in the past with Cygwin it is all too easy for you to completely give up on it. It was not only what I've mentioned specifically in this email it was much more than that. It takes quite a lot for me to give up on something entirely. The more includes: slowest file access and tools ever, unsupportive (in demonstrable instances, even anti-supportive) community, ... I had a whole structured rant at one point on a wiki I used to have access to. I should have published it before I lost access. This discussion is really just the tip of the iceberg... But I thought I should add my own suggestions and feelings to balance yours for those here who would like to give Cygwin (or MinGW+MSYS or MinGW_w64+MSYS2) a try without being too affected by our different prejudices. :-) Thanks for providing an alternate point of view. Multiple opinions are very useful when somebody new is learning, and trying to make a decision related to the discussion. Hopefully I haven't poisoned anyone irreparably with my rhetoric here. Take my comments with a grain of salt, and do your own research. I'm confident you are a smart person, and can make your own conclusions based on the evidence just fine. Happy Father's Day to all you Dads out there... David C. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Question regarding External Project add and VTK
Ok I have one final question. One of the project is built using CMake but does not contain a config file. On unix systems (make file based generators) it works fantastic, but with windows (and I presume xcode), the libraries are output to the buildtype directory. i.e. Debug/ or Release/. I can add some find_library logic to its externalproject file, and search all the possible build type directories. But it occurs to me that there might be a recipe for this. Any advice? -Jameson -- View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-External-Project-add-and-VTK-tp7587557p7587690.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] find_library and caching
Hello, I use a FindSomeLib.cmake script for my project, for which there is a variable (let's call it LINK_STATIC) to define if one wants to link against SomeLib statically. The default is to look for dynamic libraries. The issue is that when first running CMake's configure, the user may have forgotten to set LINK_STATIC, so the script finds the dynamic version of SomeLib and set a cache entry for it. Then in CMake's GUI the user realizes he wants static linking so he sets the LINK_STATIC flag, but at this point find_library has already cached the result and won't look again for static version of SomeLib. This ends up with the user thinking he's using static linking, which is not what's happening. I saw in CMake's doc that in order to let find_library search again, I'd need to clear the library entry it has found. But if I do this at each CMake configure run, it removes the interest of the cache. Would anyone know about the preferred way to fix this caching issue? I would be really grateful :) Thanks, Lucas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] find_library and caching
On 15.06.2014 19:33, Lucas Soltic wrote:
I use a FindSomeLib.cmake script for my project, for which there is a variable
(let's call it LINK_STATIC) to define if one wants to link against
SomeLib statically. The default is to look for dynamic libraries.
The issue is that when first running CMake's configure, the user may have
forgotten to set LINK_STATIC, so the script finds the dynamic version of
SomeLib and set a cache entry for it. Then in CMake's GUI the user realizes he
wants static linking so he sets the LINK_STATIC flag, but at this point
find_library has already cached the result and won't look again for static
version of SomeLib.
This ends up with the user thinking he's using static linking, which is not
what's happening.
I saw in CMake's doc that in order to let find_library search again, I'd need
to clear the library entry it has found. But if I do this at each CMake
configure run, it removes the interest of the cache.
Would anyone know about the preferred way to fix this caching issue?
I would be really grateful :)
Perhaps you could use distinct cache variables for static and shared
libraries.
e.g.
find_library(FOO_STATIC_LIBRARY ...)
find_library(FOO_SHARED_LIBRARY ...)
set(FOO_LIBRARIES )
if(FOO_LINK_STATIC)
list(APPEND FOO_LIBRARIES ${FOO_STATIC_LIBRARY})
else()
list(APPEND FOO_LIBRARIES ${FOO_SHARED_LIBRARY})
endif()
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] find_library and caching
Le 15 juin 2014 à 20:19, Nils Gladitz nilsglad...@gmail.com a écrit :
On 15.06.2014 19:33, Lucas Soltic wrote:
I use a FindSomeLib.cmake script for my project, for which there is a
variable (let's call it LINK_STATIC) to define if one wants to link
against SomeLib statically. The default is to look for dynamic libraries.
The issue is that when first running CMake's configure, the user may have
forgotten to set LINK_STATIC, so the script finds the dynamic version of
SomeLib and set a cache entry for it. Then in CMake's GUI the user realizes
he wants static linking so he sets the LINK_STATIC flag, but at this point
find_library has already cached the result and won't look again for static
version of SomeLib.
This ends up with the user thinking he's using static linking, which is not
what's happening.
I saw in CMake's doc that in order to let find_library search again, I'd
need to clear the library entry it has found. But if I do this at each CMake
configure run, it removes the interest of the cache.
Would anyone know about the preferred way to fix this caching issue?
I would be really grateful :)
Perhaps you could use distinct cache variables for static and shared
libraries.
e.g.
find_library(FOO_STATIC_LIBRARY ...)
find_library(FOO_SHARED_LIBRARY ...)
set(FOO_LIBRARIES )
if(FOO_LINK_STATIC)
list(APPEND FOO_LIBRARIES ${FOO_STATIC_LIBRARY})
else()
list(APPEND FOO_LIBRARIES ${FOO_SHARED_LIBRARY})
endif()
Nils
Oh my… really interesting idea! Thanks!!
Lucas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Cygwin drive paths are killing me
On 14/06/2014 21:31, Alan W. Irwin wrote: On 2014-06-14 12:25-0400 David Cole wrote: The difficulty of uninstalling it, and the difficulty of replicating a cygwin environment that is on one machine *exactly* on another machine with *all* the same components at *all* the same versions ... these are but 2 of the reasons I will NEVER rely on cygwin again for anything. It's just too painful, and there's absolutely NO upside. Hi Dave: Why are you holding back so much from giving us your real opinion of Cygwin? :-) Seriously though, I wonder if some of your complaints have an answer. About difficulty of uninstalling the answer is here: https://cygwin.com/faq.html#faq.setup.uninstall-all short version: - stop all cygwin programs - stop all the cygwin services - zap the cygwin directory Of course someone like me find some upsides, like having a large number of unix tools available on windows, otherwise we will have no users nor any packagers. Alan Marco PS: cmake works fine on cygwin, so thanks Dave. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Cygwin drive paths are killing me
Of course someone like me find some upsides, like having a large number of unix tools available on windows, otherwise we will have no users nor any packagers I guess over the years I've just ended up collecting small static versions of 'unix tools' in my tools folder under unix cp, rm, mv, ls, mkdir.exe, echo.exe, touch, uname, make.exe, and some less generally useful things, wget, ssh, cvs, mtn but I think of the above cmake only needs make and other things are handled with cmake -E commands and then the compiler... and make (mingw32-make) comes with mingw anyhow; so I'm pretty sure everything can build with MinGW (not MSYS), cmake, and the android NDK on a clean system. (and 30% faster than a cygwin environment) personally I can't stand how slow cygwin is; even things just built with cygwin run 30-50% slower than any other compiler... and it's really not worth it to have paths that don't really work and then redhat got ahold of it and it just went downhill from there (yes that was a long time ago) MinGW doesn't even need environment changes, just need the bin in PATH... -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] CDash quesitions
I have a dashboard set up at: http://my.cdash.org/index.php?project=Safe+Numericsfiltercount=1showfilters=1field1=buildstarttime/datecompare1=83value1=1%20year%20ago I've had a couple of problems getting it working - but it seems to work and now I have a few questions. a) I generated some bogus test results by running the Experimental target on my Xcode/Cmake project. This seems to be fixed by making sure that the test project and experimental CDash were both set to release. Also it seems I created some test results with 0 tests run but invoking Experimental target more than once. I'm not sure. b) Anyway, I have a few lines of test results that I want to eliminated - how do I remove lines from this table? Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/CDash-quesitions-tp7587696.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.0.0-1138-g8af01cd
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 8af01cd5e9b15668816b422e6a8db80d94df8bcd (commit) from 81ff6da63a7072eb7c82db9631170c2c67b1ebce (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=8af01cd5e9b15668816b422e6a8db80d94df8bcd commit 8af01cd5e9b15668816b422e6a8db80d94df8bcd Author: Kitware Robot kwro...@kitware.com AuthorDate: Mon Jun 16 00:01:06 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Mon Jun 16 00:01:06 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 8661ec4..d259a0c 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 0) -set(CMake_VERSION_PATCH 20140615) +set(CMake_VERSION_PATCH 20140616) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
