[cmake-developers] FindPythonLibs fixes for Python3
Hi,
Attached are two patches which improve Python3 support in the
FindPythonLibs.cmake module. The commit messages contain explanations
for the commits, copied here for convenience.
Subject: [PATCH 1/2] Don't put legacy variables back into the cache
If PYTHON_INCLUDE_PATH is put into the cache, then it will always
override whatever might be found and PYTHON_INCLUDE_DIR is never given a
chance to find something different. It being marked as INTERNAL also
means that it cannot be changed without editing CMakeCache.txt directly.
Basically, the scenario is that if the Python version is changed, then
deleting PYTHON_INCLUDE_DIR doesn't work because any cached
PYTHON_INCLUDE_PATH variable is set before find_path is even called. Any
build tree using a previous version will still need either manual
removal of PYTHON_INCLUDE_PATH or a complete reconfigure, but in the
future changing the Python version can be accomplished by deleting
PYTHON_INCLUDE_DIR and reconfiguring with the new version.
Subject: [PATCH 2/2] Search for other ABIFLAGS builds of Python
Starting with Python3, standard Python installs may have additional ABI
flags attached to include directories and library names. As of 3.2, the
following flags are in the configure file:
d -> --with-debug
m -> --with-pymalloc
u -> --with-wide-unicode
Python 3.3 seems to no longer have --with-wide-unicode. Hopefully Python
will ensure that the possible flags always show up in a stable order.
The 'd' flag is ignored since the debug library is considered separate.
There is still the problem where ABI flags cannot be specified in
find_package since the letters confuse the version comparator.
--Ben
>From 6a46f5ce809185e0c7dbd3d618eb4bbde808827b Mon Sep 17 00:00:00 2001
From: Ben Boeckel
Date: Tue, 27 Mar 2012 16:21:06 -0400
Subject: [PATCH 1/2] Don't put legacy variables back into the cache
If PYTHON_INCLUDE_PATH is put into the cache, then it will always
override whatever might be found and PYTHON_INCLUDE_DIR is never given a
chance to find something different. It being marked as INTERNAL also
means that it cannot be changed without editing CMakeCache.txt directly.
Basically, the scenario is that if the Python version is changed, then
deleting PYTHON_INCLUDE_DIR doesn't work because any cached
PYTHON_INCLUDE_PATH variable is set before find_path is even called. Any
build tree using a previous version will still need either manual
removal of PYTHON_INCLUDE_PATH or a complete reconfigure, but in the
future changing the Python version can be accomplished by deleting
PYTHON_INCLUDE_DIR and reconfiguring with the new version.
---
Modules/FindPythonLibs.cmake |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index fcd0838..e833150 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -123,9 +123,8 @@ FOREACH(_CURRENT_VERSION ${_Python_VERSIONS})
python${_CURRENT_VERSION}
)
- # For backward compatibility, set PYTHON_INCLUDE_PATH, but make it internal.
- SET(PYTHON_INCLUDE_PATH "${PYTHON_INCLUDE_DIR}" CACHE INTERNAL
-"Path to where Python.h is found (deprecated)")
+ # For backward compatibility, set PYTHON_INCLUDE_PATH.
+ SET(PYTHON_INCLUDE_PATH "${PYTHON_INCLUDE_DIR}")
IF(PYTHON_INCLUDE_DIR AND EXISTS "${PYTHON_INCLUDE_DIR}/patchlevel.h")
FILE(STRINGS "${PYTHON_INCLUDE_DIR}/patchlevel.h" python_version_str
--
1.7.6.5
>From 4bdec581b3a5a32239370e87aa2f7cadcb058aae Mon Sep 17 00:00:00 2001
From: Ben Boeckel
Date: Tue, 27 Mar 2012 16:24:43 -0400
Subject: [PATCH 2/2] Search for other ABIFLAGS builds of Python
Starting with Python3, standard Python installs may have additional ABI
flags attached to include directories and library names. As of 3.2, the
following flags are in the configure file:
d -> --with-debug
m -> --with-pymalloc
u -> --with-wide-unicode
Python 3.3 seems to no longer have --with-wide-unicode. Hopefully Python
will ensure that the possible flags always show up in a stable order.
The 'd' flag is ignored since the debug library is considered separate.
There is still the problem where ABI flags cannot be specified in
find_package since the letters confuse the version comparator.
---
Modules/FindPythonLibs.cmake | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Modules/FindPythonLibs.cmake b/Modules/FindPythonLibs.cmake
index e833150..591b3e6 100644
--- a/Modules/FindPythonLibs.cmake
+++ b/Modules/FindPythonLibs.cmake
@@ -82,7 +82,12 @@ FOREACH(_CURRENT_VERSION ${_Python_VERSIONS})
ENDIF(WIN32)
FIND_LIBRARY(PYTHON_LIBRARY
-NAMES python${_CURRENT_VERSION_NO_DOTS} python${_CURRENT_VERSION}
+NAMES
+python${_CURRENT_VERSION_NO_DOTS}
+python${_CURRENT_VERSION}mu
+python${_CURRENT_VERSION}m
+python${_CUR
Re: [cmake-developers] ninja command line options ?
On Tue, Apr 03, 2012 at 20:02:38 +0200, Alexander Neundorf wrote: > I'm thinking about giving ninja + Eclipse a try. > Short question: > * how do I tell ninja to build a specific target ? ninja $target > * is there a special way to "clean" ? ninja -t clean Also see ninja -t list for other special commands. > * how do I tell ninja to use multiple threads/processes (like -j for make) ? ninja -jX (default seems to be N + 2; N == number of "cores" available) > * is the syntax the same for Windows and Linux ? I'm pretty sure it is. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
On Tue, Apr 03, 2012 at 12:48:06 -0400, Bill Hoffman wrote: > Hi, I just wanted to get an update on the ninja generator status. > Right now all linux tests are passing, and that platform seems to be > done. I've run into this[1] bug. I can make a testcase for it tomorrow. --Ben [1]http://public.kitware.com/Bug/view.php?id=13069 -- 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] FindCXX11.cmake
On Mon, Apr 09, 2012 at 23:44:23 +0400, Yury G. Kudryashov wrote: > # check for two required features > check_cxx11_features(feature1 feature2 REQUIRED) Why not have REQUIRED first? It would make more sense with the next syntax. > # check for optional AND required features > check_cxx11_features( > REQUIRED required1 required2 > OPTIONAL optional1 optional2) --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Target usage requirements and conventions
On Thu, May 03, 2012 at 09:35:44 -0600, Clinton Stimpson wrote: > The include, defines, etc... can be properties on a target when when > target_use_target() is used, it could extract those properties and apply them > on the using target. So we'll also need a way to define private values for these things as well. Linking some abstraction library should not automatically link the abstracted library, add its header path, or add any defines for it to targets that use the abstraction library. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Using tags in Mantis
Hi, I was wondering what folks thought of going through the bug tracker and attaching tags to bugs to help bubble some up to the top. Some tags are used, but it doesn't seem all that consistent in usage or style. To start with, how about tags such as: cmake-patch - Patch attached to the bug (or diff in the comments). cmake-ezfix - Easy fixes for new contributors. cmake-need-policy - Bugs which need a policy to be fixed properly. cmake-rfe - Feature requests. cmake-gen-$generator - Generator-related bugs (ninja, make, eclipse, vs$year, xcode, etc.). cmake-platform-$platform - Platform-specific bugs (Windows, OSX, Linux, etc.). cmake-compiler-$compiler - Compiler-specific bugs (xlc, gcc, clang, etc.). cmake-lang-$lang - Language-specific bugs (c, cxx, java, etc.) cmake-policy-$policy - Policy-related bugs. cmake-find-pkg-$package - FindXXX.cmake-related bugs. cmake-pony - Bugs wishing for CMake to help ponies fly. The 'cmake-' prefix is because the bug tracker is also used for other projects. This would also probably be a good time to close bugs which got skipped over (I found one of mine which was fixed, but that never got back to mantis). Any other tags which would be useful (maybe not cmake-pony...)? How much would tags be used? Would they be helpful? --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using tags in Mantis
On Thu, Nov 21, 2013 at 10:51:29 -0500, David Cole wrote: > >I was wondering what folks thought of going through the bug tracker > and > >attaching tags to bugs to help bubble some up to the top. > > How would this bubble anything to the top? There are bugs with patches attached to them yet, probably lost in the deluge. Having patches ignored (not even rejected) is, IMO, one of the more demoralizing things when contributing to new projects. It would also help to pinpoint the easy bugs to tackle. > It would categorize and organize, perhaps, but there are still N open > bugs where N is larger than any of us would like... Agreed. > I suppose it might help some people look at a smaller, > more-interesting-to-them subset. That's the idea :) . > I would think before categorizing and organizing, you would want to > minimize the tagging task itself i.e. -- close out old bugs that > are now already fixed or irrelevant, and fix and resolve as many as > possible before organizing the remainder. If folks are going to be going through bugs *anyways*, tagging as you're looking for easy-to-close bugs wouldn't be that hard. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review Request: Topic ExternalProject_GitUpdate
On Mon, Nov 18, 2013 at 12:19:55 +0100, Daniele E. Domenichelli wrote: > If there are local changes, "git stash" is used to save the > changes and restore them after the pull. If any of these operation > fails, it tries to restore the original status and exits with a fatal > error, asking the user to resolve the conflicts manually. I like the `--all` usage, but I see that `--index` is passed to `stash pop`, but `--keep-index` isn't passed to `stash save`. Is this intended? --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review Request: Topic ExternalProject_GitUpdate
On Tue, Dec 03, 2013 at 23:09:38 +0100, Daniele E. Domenichelli wrote: > git stash save automatically saves the index, that is restored using git > stash pop --index. The --keep-index does not save the index but instead > keeps it in the working tree. > This means that after stashing you will still have a dirty working tree, > and therefore rebase will fail. Ah, right. Misread the docs for it. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On Thu, Dec 12, 2013 at 00:00:42 +0100, Stephen Kelly wrote: > You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED: > > https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html > > I continue to consider the default value of that to be a mistake. How would a relink be forced with the default of "ON" when the ABI does break? Would I need to invoke the targets manually? That sounds painful to me. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On Wed, Dec 11, 2013 at 17:40:08 -0500, Bill Hoffman wrote: > The other option sounds interesting but hard to implement in a cross > platform manner. Maybe an option to use this[1] tool would be useful? --Ben [1]http://ispras.linuxbase.org/index.php/ABI_compliance_checker -- 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] cmake build does too much work
On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote: > Now, I *do* get that relinking is good if the library ABI changes. > However, that's not the case here, and I am wondering if it would be > possible for CMake to generate an additional, intermediary step after > library linking to somehow export a file representing the ABI of the > library (with overwrite checks to not modify the file if the ABI has > not changed), and to use *those*, rather than the actual libraries, > as the dependencies for targets linking to the libraries. I think > this could produce a significant speed-up for incremental builds in > some cases, as it would allow the build to short-circuit the relink > of many targets when it turns out a library's ABI has not changed. While the tool I posted in the other message is a possibility, how would you deal with inline functions changing? Same with template implementations? For example, when a Boost *header* changes, dependencies need to be recompiled to get the new inline code. Which build systems actually have that level of granularity? Does XCode or VS track external dependencies on the file level? I don't *think* make and ninja do so, since after a GCC upgrade, my trees don't all of a sudden do a full rebuild (and after upgrading from Fedora N to N+1, nuking build trees is usually on the menu due to new soversions of libraries shifting around; a simple rebuild misses this). --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On Wed, Dec 11, 2013 at 19:38:21 -0500, Matthew Woehlke wrote: > I don't think this is relevant? In these cases, a header is changing, > which will (hopefully) lead to the source files using that header > being rebuilt, which will cause the library to relink anyway. (And if > the sources *aren't* rebuilt, I don't think relinking will help?) I'm concerned about this: (external) (internal) template.hpp <-- A.cpp --> header.h ^^ || |\- liba.so | ^ | | \-- B.cpp <-- libb.so Where template.hpp changes (testing with 2.8.12.1 shows that touching template.hpp triggers a rebuild with Ninja, but not Unix Makefiles), internal_header.h changes and A.cpp gets recompiled, liba.so relinked and libb.so skipped because the ABI hasn't changed. The problem is that if something inlined from template.hpp is incompatible with what B.cpp has inlined, things need recompiled. I don't know how other tools work, but Unix Makefiles are certainly popular enough that I'd like to see that this cannot cause problems first. Of course, the fix may be to have A.cpp depend on template.hpp directly. I don't know the cost of this in for the build or generate time (but possibly noticable with files which include a lot). > I would expect the behavior for external dependencies would not > change; they would either trigger rebuilds or not the same as they do > currently. (Since of course we cannot rely on having 'ABI stamp > files' for any external libraries...) Maybe the problem I was referencing was out-of-scope. I wonder if abi-compliance-checker handles mismatches between inlined symbols (mostly a problem outside of -fvisibility=hidden). --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On Thu, Dec 12, 2013 at 11:46:24 -0500, Matthew Woehlke wrote: > Actually... back up for a moment. Since we're talking about dynamic > libraries here (none of this applies to static I think; in that case > you must always relink), how would a non-ABI change in liba.so cause > the result of linking to be different? I didn't think dynamic linking > involved *copying* symbols from liba into libb? True. Thinking about it more, I do agree with Bill that pretty much any intentional ABI change is going to have something in a header change in common code; you could certainly *try* and break this pretty easily by removing implementations of functions or template specializations, creating symbol collisions, and probably more. However, these sound like errors that would occur anyways with fairly explicit errors at runtime (maybe not duplicate symbols). What I'm worried about are problems where a link would have resolved it, but it's some weird, subtle, error at runtime. Also, how would this interact with link-time optimization? I don't seem much on how (if at all) LTO works with shared linking, but there do seem to be bugs[1][2]. --Ben [1]http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 [2]http://stackoverflow.com/questions/19593919/lto-and-virtual-destructor-weirdness-c -- 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] Generators and Extra Generators
On Tue, Jan 07, 2014 at 17:37:11 +0100, Stephen Kelly wrote: > I'd like to see cmake generate all the info a UI would need in a simple and > non-tied-to-a-particular-implementation way. That would be something Qt > Creator and Kate could use as it would list the targets, the compile lines > for objects, link targets, link lines etc. As far as I know, QtCreator uses > the CodeBlocks generator because it contains all that relevant information > as an xml file. Something like this[1]? --Ben [1]http://clang.llvm.org/docs/JSONCompilationDatabase.html -- 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] Generators and Extra Generators
On Tue, Jan 07, 2014 at 18:42:37 +0100, Stephen Kelly wrote: > Is that all that's needed, do you think? Well, it handles the commands required at least. Adding keys to the objects for targets and output file(s) would be the next step I'd think if IDE developers are amenable to using it. It's simple enough that ninja itself could even dump it out. I don't know how crazy it should get though; you'd be getting pretty close to ninja rules files themselves after too much time. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On Thu, Jan 16, 2014 at 08:41:58 -0700, Clinton Stimpson wrote: > I'm surprised how this small change added a 20% slowdown. > -set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG) > +set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$ $>:QT_NO_DEBUG>) There's a lot of places where std::string gets passed as a const char* only to be turned back into a std::string in the function. Would it be worth me trying to resurrect that branch again? It wasn't worth much last I tried, but that was before a lot of the generator expression stuff was added. I guess another question is whether the genex is evaluated once or per-target (I'd guess the latter which might be the reason especially if Qt4 is found at the top-level of a larger project). --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_CONFIGURATION_TYPES
On Wed, Feb 05, 2014 at 12:00:41 -0700, Steve Wilson wrote: > In the documentation for CMAKE_CONFIGURATION_TYPES it states: > > “… but can be extended to provide other build types. … “ > > How would one provide other build types? It's just a list with a default of "Release;RelWithDebInfo;RelMinSize;Debug", so just add your configuration name to the list. Please do *not* set it in other generators which don't already use it (they use CMAKE_BUILD_TYPE) since they only generate for a single build type at a time and some projects have to detect whether subdirectories will be thrown into places by the build for various reasons[1]. In order for any custom configurations to be *useful*, you'd have to populate the variables for them (e.g., CMAKE_CXX_FLAGS_ and friends). --Ben [1]The one I usually have to deal with is Python builds where I want to move the configuration directory to a different place: lib/python/$/.../module.so rather than: lib/python/.../$/module.so For make and Ninja generators, such hackery isn't necessary because there isn't an implicit subdirectory. Of course, if there is some way to detect these generators other than CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE, that would be nice as well :) . -- 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] [PSA] API changes to use strings
[ TL;DR: If you're thinking you might need .c_str(), try it without and
possibly avoid a string reallocation :) . ]
Hi,
I am merging a branch into next later today which changes APIs to use
std::string instead of const char* for things such as:
- target names
- property names
- variable names
- test names
which should *never* be NULL anyways and usually get turned into strings
behind the scenes anyways. The values for them can be NULL, but the
names are always constructed by CMake itself, so should be empty at
worst. The changes which change call sites to not use .c_str() on
variables which are already strings is too conflict-y at this point, but
should land soon after 3.0 is released. The purpose of landing the API
changes early is so that new code may use the new APIs and my branch
doesn't need to keep being rebased to pick up new changes. For those
interested, here's a comparison of before and after my branch:
% git grep -w c_str master | wc -l
5356
% git grep -w c_str HEAD | wc -l
4048
Other than those changes listed above, there are also a few other API
changes to be aware of:
- cmStrCmp() can now take a std::string constructor and stores a
string internally.
- The cmMakefile::GetPropertyOrDefinition method is removed; it was
not used anywhere.
- cmMakefile::Get{Source,Header}Extensions returns a std::set rather
than a std::vector since it was never modified and is only iterated
over and searched in other code.
- cmLocalGenerator::Convert and related methods now take a string as
the first argument.
Other API changes will be made as well, but they will be backwards
compatible. Methods which take a value for a property or variable will
gain a std::string overload for that argument while the const char*
variant will check for NULL then pass control off to the std::string
overload.
The commit messages probably need some rewording before final merge.
Squashing is also likely to happen (these changes have been extracted
from my main branch which makes some commits much more substantial).
As a PSA, some other patterns I've seen that I'm trying to kill with
fire on the conflict-y part of the branch:
{ // One branch ("kill c_str").
stream << str.c_str()
str = otherstr.c_str()
str = std::string("static") + otherstr
const char* cstr = str.c_str()
// then use cstr in strcmp or casted into string later. These are
// harder to find. Removing .c_str() calls makes it easier.
}
{ // Possibly separate branches.
if (Lookup(var))
{
std::string str = Lookup(var);
}
vec[vec.size()-1] (use *vec.rbegin())
if (container.size() > 0) (use .empty())
sprintf(staticbuf, ...) (use snprintf)
// Not really a performance thing, just something I noticed while
// poking around the code for the other changes.
}
If there are any other patterns that belong on this branch (or in the
sweep), please let me know and I'll throw it on the pile.
The goal of all of this? To make CMake faster by removing the chaff in
callgrind runs. String allocations and strlen/memcmp in string/C string
comparisons are way too high and hide other bottlenecks, so I'm whacking
the vast majority of problems with a very large hammer here.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] add_custom_command differences in tests
On Thu, Feb 06, 2014 at 17:30:11 -0700, Steve Wilson wrote: > I have my topic branch with the add_custom_command changes to include > the CONFIG keyword working.The CMake binary produced from the > build will correctly generated build systems that have custom commands > with the CONFIG keyword. I’m having trouble writing tests for the > changes though. When I run add_custom_command with the CONFIG > keyword in the test suite the CONFIG keyword does not work. > > I need a little guidance with the test suite. I’m not super familiar > with CTest so I’m not sure where to look next to find the problem. > So my question: Why would add_custom_command behave differently in > the tests than in regular build system generation? Hmm. Are you using your installed ctest or the build tree's ctest? If the former, it may be using your installed cmake. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PSA] API changes to use strings
On Thu, Feb 06, 2014 at 23:44:51 +0100, Stephen Kelly wrote:
> Ben Boeckel wrote:
> > - cmMakefile::Get{Source,Header}Extensions returns a std::set rather
> > than a std::vector since it was never modified and is only iterated
> > over and searched in other code.
> The justification is strange. Generally, the guideline with C++ stl
> containers is to use std::vector unless you have a good reason to use
> something else.
It's read-only after construction, so with std::set we get
std::binary_search for free since we never have to pay set's insertion
penalty over time.
> > vec[vec.size()-1] (use *vec.rbegin())
> vec.back() ?
Err, for vectors, that works. I got mixed up with my examples. For
std::string, you need .rbegin() since .back() is C++11 there.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Preparing for CMake 3.0-rc1
On Fri, Feb 07, 2014 at 13:57:28 -0500, Brad King wrote: > Comments? So…"what the Linux kernel did"? :) I like it. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Branches on next
Hi, I've just pushed two branches into next: dev/custom-parsers Replaces the parsers in cmMakefile::ExpandVariablesInString with custom code rather than lex/yacc. The parsers in cmGeneratorExpression::StripEmptyListElements cmSystemTools::ExpandListArguments and have been optimized to not do char-by-char result building and cmGeneratorExpressionLexer::Tokenize now uses a switch statement. These gain about 20% in the configure step (generate is largely unchanged; maybe 33% for Makefiles (though Makefiles generate faster than the configure for ParaView) and minimal for Ninja). dev/fix-sublime-compile-flags Fixes a typo in the sublime generator (found while working on another branch). Please test the custom-parsers branch. The tests pass, but if there are any corner cases there, new tests should be included. Testing on non-Linux would be nice as well. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)
On Tue, Feb 11, 2014 at 15:54:40 -0500, Brad King wrote:
> Why does each level in the openstack need to hold its "lookup"
> member? Can't everything be stored in-place in the work buffer?
> Each openstack level just needs to track the start character in
> the work buffer. When that level is closed the work buffer
> should contain the exact lookup string from the open position
> to the end. Then PUSH((x)) can be replaced with just
> "work.append(x)".
The problem is stuff like x${CMAKE_${LANG}_FLAGS}. While parsing, we
need to store "x" in the result, then "CMAKE_" in another place. When
"LANG" is expanded, it goes into the "CMAKE_" buffer which can't be
stored in-place anymore. When the last '}' is reached, we take the
latest buffer, put the last parts to parse into it then lookup that
variable.
Some things that have crossed my mind for further changes is to just
store the result at the bottom of the stack and check that .size() == 1
at the end. This avoids .empty() checks for each hunk and makes the code
smaller. Some logic last/lookup.start when the lookup string is empty
could also possibly be changed, but I've haven't done so yet.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)
On Tue, Feb 11, 2014 at 15:54:40 -0500, Brad King wrote: > Why does each level in the openstack need to hold its "lookup" > member? Can't everything be stored in-place in the work buffer? < in-person discussion of the algorithm > After looking at the implementation, it may not save much since we'll need to make a std::string to call out to GetDefinitions anyways pending dev/string-apis, so the need to make strings exists already, so just using char* references into the result array won't save a construction (a string is made down below when calling .find() on the variable storage, so even making an overload won't save a string construction). --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On Tue, Feb 11, 2014 at 17:18:22 -0500, Matthew Woehlke wrote:
> On a loosely related note, did you know that there are now at least
> two Python parsers for CMake script? (Besides I believe a C++ one in
> KDevelop...)
>
> 1. https://github.com/ijt/cmakelists_parsing
> 2.
> https://github.com/mwoehlke-kitware/Slicer/blob/3269-publish-extension-wizard/Utilities/Scripts/SlicerWizard/CMakeParser.py
>
> It would be interesting to know how accurate these are. (Although if
> the README for the (1) is accurate, that one isn't anything to write
> home about.)
>
> (One reason I mention it is because when I wrote (2), I made an
> attempt to look at CMake's own parsing code. Alas, I do not speak
> lex...)
Parsing in CMake is split into separate sections: the part which parses
the lines into CMake's command calls and the part which expands
variables (which is why "${cmd}(${args})" isn't allowed).
ExpandVariablesInString is the part which takes a string which may have
variables in it and dereferences them. It also handles @-expansion.
The basics aren't too hard…it's the corner cases and known what the
various parameters are in different parts of the code. These include
whether quotes are escaped or not, whether to actually deal with escape
characters, and whether it is @-only.
If you're looking for corner-cases, check out the RunCMake.Syntax test
in the source tree. If you can handle that, you're probably doing pretty
well on the basics. If you actually want to know what CMake will do when
it gets somewhere, you actually have to parse the code.
Corner cases I hit while developing the new parser:
- in "\@var@", 'var' is expanded;
- "${@var@}" and "@${var}@" are *not* the same (all @ expansion takes
place before any ${} expansion);
- '\n', '\t', and '\r' are only interpreted in certain contexts (see
noEscapes in the EVIS method);
- '\;' is always literal (don't ask why, but if you don't keep the
slash around, things fail);
- in '@var@', if 'var' is empty, it is left alone…sometimes (the
removeEmpty parameter);
- don't forget "$CACHE{}".
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
> On 2014-02-11 17:54, Ben Boeckel wrote:
> >Parsing in CMake is split into separate sections: the part which parses
> >the lines into CMake's command calls and the part which expands
> >variables (which is why "${cmd}(${args})" isn't allowed).
>
> Right; I'd figured that much out on my own, and my own parser AFAICT
> operates in a similar manner to CMake itself... it doesn't try to
> tokenize variable substitutions (I didn't need that, and it would
> have made the API non-trivially more complex), although it does choke
> if it seems things like '${foo\n'. From what I can tell, the CMake
> command parsing pass does also?
Probably worth a test. The new parser will see:
${foo
}
and happily lookup the "foo\n" variable. The old parser may have choked.
FWIW, variables named as such can still come in through CMakeCache.txt
and probably the command line as well, so maybe there's some value here.
If it's wanted, I can tighten up the new implementation (it's also the
perfect release version to start rejecting junk like ';' or ' ' in
variable names, but it is probably too late in the release cycle at this
point).
> >ExpandVariablesInString is the part which takes a string which may have
> >variables in it and dereferences them.
>
> Yes, that's why your changes are probably not all that helpful to
> understanding CMake's parsing... one must first understand the
> initial parse pass, which I assume is still in lex (unless you
> rewrote it too and forgot to mention it ;-), which I doubt).
That code isn't even on the radar for expensive code. It probably could
be replaced with smaller code other than lex/yacc, but it's not worth
the time if performance is the goal (removing lines, however…). Anything
other than comments and blank lines is always in the form:
"(" ")"
which is pretty fast (the parser is also set up once per file; the EVIS
lex/yacc parser was set up and torn down for *each* expansion which is
generally per-line which contains any of "@$\\").
> >Corner cases I hit while developing the new parser:
> >
> > - in "\@var@", 'var' is expanded;
>
> Is '@var@' actually expanded in plain CMake script? (OMG... it is...)
>
> I wonder how many people are even aware of this. At any rate, at
> least kate doesn't highlight it. (vim doesn't either, but vim also
> doesn't highlight '${var}', so no surprise it doesn't.)
>
> Alas, my parser does not accept these at present.
It was news to me as well. In any case, it's only expanded if 'var' is
defined (and it must occur all on one line). For the
configure_file(@ONLY) command, it will expand @var@ to empty strings
however. It's a backwards compat thing; see bug 2722.
> > - '\;' is always literal (don't ask why, but if you don't keep the
> >slash around, things fail);
>
> Oh, ick... right now I'm not handling ';' as special but as literal
> text of an argument. If anyone is using that instead of whitespace as
> an argument specifier, then too bad :-). (For now at least, since
> fixing it will require some odd fiddling with the API. Or possibly
> declaring that ';' now counts as whitespace :P.)
>
> AFAICT, \; is only an escape when it *isn't* quoted. In quotes it's
> just two normal characters. (This appears to be the only escape that
> behaves differently quoted versus not.)
Yeah, I think if the string is quoted, the 'noEscapes' is false which is
where it acts…weird. I think it has to do with nested lists breaking if
the semicolon disappears or something (ExpandListArguments deals with
escaped semicolons and nothing else).
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On Tue, Feb 11, 2014 at 14:49:42 -0500, Ben Boeckel wrote: > (though Makefiles generate faster than the configure for > ParaView) and minimal for Ninja). I've addressed this…at least 2x speedup of Ninja's generate time in ParaView (2.8.12.2: 95 seconds; branch with *all* performance changes: < 40 seconds; something like 55 with just the Ninja changes). It will show up on the stage in a bit. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On Wed, Feb 12, 2014 at 11:46:39 -0500, Matthew Woehlke wrote:
> >That code isn't even on the radar for expensive code. It probably could
> >be replaced with smaller code other than lex/yacc, but it's not worth
> >the time if performance is the goal (removing lines, however…). Anything
> >other than comments and blank lines is always in the form:
> >
> > "(" ")"
> >
> >which is pretty fast (the parser is also set up once per file; the EVIS
> >lex/yacc parser was set up and torn down for *each* expansion which is
> >generally per-line which contains any of "@$\\").
>
> Related: does the first pass then completely ignore these characters
> (and also genex's AFAICT?) and only perform argument splitting based
> on whitespace and '"'?
>
> I'm wondering, since I don't try to tokenize expansions anyway, if I
> can just get rid of that part of my parsing without harm...
Also bracket'd arguments (which, IIRC, have the highest priority).
Generator expressions are 100% ignored (other than not triggering errors
related to the '$' being used "improperly") until generate time.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On Wed, Feb 12, 2014 at 11:42:53 -0500, Ben Boeckel wrote:
> I've addressed this…at least 2x speedup of Ninja's generate time in
> ParaView (2.8.12.2: 95 seconds; branch with *all* performance changes: <
> 40 seconds; something like 55 with just the Ninja changes). It will show
> up on the stage in a bit.
This has been pushed; the custom-parsers branch has been reverted due to
many corner cases still existing (interactions between @ and ${}
expansion and it being to lax in literal characters allowed in variable
names).
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Branches on next
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
> >If you're looking for corner-cases, check out the RunCMake.Syntax test
> >in the source tree. If you can handle that, you're probably doing pretty
> >well on the basics.
>
> Thanks; I may do that some time.
Also look at RunCMake.variable_expansion (on next).
Speaking of corner cases, one evil case I thought up of is not as evil
as it could have been:
set(0 TRUE)
if (0)
message("madness")
else ()
message("actually called")
endif ()
This is however, is slightly evil:
set(zero 00)
if (zero)
message("actually called")
else ()
message("well, it was a nice thought")
endif ()
if (${zero})
message("wait a minute...")
else ()
message("actually called")
endif ()
Not sure how if want to handle that with a policy or not.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Objective-C support
On Fri, Feb 14, 2014 at 17:22:13 -0500, Sean McBride wrote: > Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super > stable. Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking std::string ABI with C++11 support enabled (4.7.2 fixed it to be compatible with < 4.7.0 and I'd, personally, blacklist those two versions if you use C++11). --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Objective-C support
On Fri, Feb 14, 2014 at 18:02:18 -0500, Sean McBride wrote: > What I mean is that with C++, and STL especially, it's hard to build a > library with a given compiler/standard library combination and link > that library into an executable built with a different > compiler/standard library combination. (Harder than with say C.) > That's the case on any platform. I was only trying to point out that > 10.9 Mavericks is not special in this regard. Ah, so standard library *compatibility*, not *stability* then? I agree with that. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GIT push access please
On Sat, Feb 15, 2014 at 22:53:42 +, Dan Cristiu wrote: > I'd like to push a couple of changes to the VS11/12 generators. They > are currently ignoring non-default CMake platforms, with the > exception of WinCE. Found a bug related to this issue: > http://public.kitware.com/Bug/view.php?id=14673 Sounds like a nice improvement. > Would appreciate if anyone could give me a hand in obtaining > developer access. Instructions are on the wiki: http://www.cmake.org/Wiki/CMake/Git/Develop http://www.cmake.org/Wiki/CMake/Git/Account#Git 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] New EVIS parser moving forward (3.1)
Since the current ExpandVariablesInString has all kinds of pitfalls and
corner cases plus how close to the core of CMake this code change is, it
seems that a policy is warranted. Since the new parser is fast enough,
in the WARN case, it will run both the new and the old parsers and warn
when the expansion is different (or causes errors) because of the new
rules.
The other parser improvements (generator expressions and list expansion)
have been split out so that they may make it into 3.0 (ideally).
Things that I plan on changing with the new EVIS parser:
- No more '(' or ')' allowed in literal variable names. Previously,
these were only allowed in quoted $ENV{} expansions (though with my
(admittedly) limited lex/yacc knowledge, I don't see why this was
allowed anyways). I don't think there's much of a loss here,
personally. There may be other allowed characters no longer allowed,
so for the sake of clarity, the only *literal* characters allowed in
variable names will be alphanumeric, '_', '-', '/', '+', and '.'. If
you really need other characters, this still works since variable
expansions are not looked at:
set(varname "parens(k)")
message("$ENV{${varname}}")
- @ expansion is no longer done in CMakeLists.txt, included files, for
modules. This is probably a little-known "feature" that I have no
problem with nuking from orbit (see bug #2722). To get @ expansion
with the new EVIS parser, either configure_file or string(CONFIGURE)
must be used. See the code and results from
Tests/RunCMake/Syntax/AtWithVariable*.cmake for some of the
weirdness the current @ expansion causes.
Are there any other corner cases I should consider banning as well? What
about behavior that should be allowed that currently isn't?
Brad informed me that Stephen Kelly is already working on two other
policies and CMP0050 is the latest on master, so I'll take CMP0053 for
the new EVIS parser behavior.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Tue, Feb 18, 2014 at 12:13:31 -0500, Brad King wrote:
> Environment variable names can contain '(' or ')', at least on Windows:
>
> >set a(b)=c
> >echo %a(b)%
> c
>
> Perhaps this obscure case can be supported with nested evaluation though.
You can do it with the setenv(3) call in Linux as well, but bash doesn't
like it at all (env(1) can do it though). csh's setenv allows it too.
The fact that they were only supported when quoted (probably because of
the command-parser step) is surprising enough that I'd say we can just
use indirection to handle it.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Tue, Feb 18, 2014 at 17:16:07 +0100, Stephen Kelly wrote: > The improvements to the genex handling look fine, but I don't see a great > need to get this into 3.0. That minimizes the amount of time that it gets > tested, instead of maximizing it as happens by merging it just after 3.0. > For this parsing stuff, I'd consider that more important. It does seem that there are internal MSBuild errors[1] being thrown due to the branch :( . I'll take it off next until I sit down with VS and figure out what's wrong. --Ben [1]http://open.cdash.org/testDetails.php?test=236472710&build=3224712 -- 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] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 08:38:35 +0100, Rolf Eike Beer wrote:
> > Are there any other corner cases I should consider banning as well? What
> > about behavior that should be allowed that currently isn't?
>
> If this patch is the right place to address this is not clear to me, but I
> mention them anyway.
These are both if()-related behaviors. The EVIS parser *only* expands
${} and @@ variables. The treat-literal-as-variable name is implemented
by cmIfCommand::GetVariableOrString by which point quoted-ness has been
lost. The hex support would be in cmSystemTools::VersionCompare; the
parser doesn't care at all if you use "literal" hex values. Hint: There
are no integers in CMake; they're all strings and interpreted with atoi
when necessary.
> -if a string is quoted, it may still be expanded as a variable name as I have
> heard, i.e. those 2 may act as the same:
>
> if ("a" STREQUAL b)
> if (${a} STREQUAL ${b})
Worse, the former may also really be either of:
> if (a STREQUAL ${b})
> if (${a} STREQUAL b)
depending on which is defined.
> I would not expect such behavior, in fact I consider this counterintuitive.
I agree in general, however, my CMake style is to quote all variable
expansions unless I want argument splitting. This rule would break code
like this:
if ("CMAKE_${LANG}_FLAGS")
endif ()
which would be unfortunate, IMO. I don't think "quoted isn't expanded
unless it is a single word with a nested variable expansion" is an
obvious rule either. We could certainly make it so that anything with
spaces isn't expanded which should take care of some of the more
egregious cases. Maybe we should just deprecate implicit expansion in
if()? That wouldn't be that hard of a policy to implement. I don't know
how happy people would be with it though.
Looking at this code, this expansion is missing --warn-uninitialized
support. I don't know if it is worth it to implement it here since I
imagine the false-positives would be legion.
> -support for hex numbers would be cool, especially for parsing the version
> numbers out of header files (like OpenSSL).
This would be beneficial, I agree.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 14:18:02 -0500, Jean-Christophe Fillion-Robin wrote:
> On Fri, Feb 21, 2014 at 12:05 PM, Ben Boeckel wrote:
> > I agree in general, however, my CMake style is to quote all variable
> > expansions unless I want argument splitting. This rule would break code
> > like this:
> >
> > if ("CMAKE_${LANG}_FLAGS")
> > endif ()
> >
> > which would be unfortunate, IMO.
>
> As a quick check, I ran the following search on CMake code base and it
> returns nothing:
>
>cd ./CMake-src
>ack --cmake "\(\s*\"[a-zA-Z0-9]+\$"
>
> Also nothing for Slicer, ITKv4, VTK6, ...
Yeah, I don't expect it to be common.
As a more extensive check, the following gives no results in ParaView,
VTK, or VXL which one would expect the name quoted string to be treated
as a variable name:
git grep 'if\s*(' -- '*.cmake' '**/CMakeLists.txt' | \
grep --color=yes -e '"\([^$ ][^"]\+\)\?"'
It does miss multi-line if statements though.
> If possible, not having implicit expansion for quoted argument would be
> great at make things more intuitive and practical.
If I made a branch which warned when implicit expansion was done, would
folks be willing to run it over various codebases to see how annoying it
would be to just remove it altogether? I agree that the quoted rule
would be nice, but it would require passing quoted-ness flags along with
the arguments themselves to the commands which would require an API
change (or a forwarding overload with a good default implementation) to
the cmCommand base class.
Another thing which I've run across is:
if (TRUE)
endif ()
doesn't try to look up ${TRUE} (which I 100% agree with), but it means
that variables named 'TRUE' (and any other string for which IsOn and
IsOff returns 'true' for) act differently than variables with other
names.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 15:34:44 -0500, Matthew Woehlke wrote:
> On 2014-02-21 14:51, Ben Boeckel wrote:
> >If I made a branch which warned when implicit expansion was done, would
> >folks be willing to run it over various codebases to see how annoying it
> >would be to just remove it altogether?
>
> To be clear, are we talking about in the case of e.g. STREQUAL, or
> *ever*? Because I'm sure breaking 'if(Pkg_FOUND)' would be very, very
> bad :-).
My thought was "ever", but for direct variable tests we could support
implicit dereference. We'd have to document that testing the variable
"TRUE" requires a dereference though (or we could just ban variables
with names for which either IsOn or IsOff returns 'true' altogether
since that is where if() skips the dereference).
> I'd be a little suspicious of even the former; I know at least in my
> case, greater understanding of implicit expansion leads to greater
> *reliance* on it as a guard against unintended expansion (i.e. 'if
> (FOO STREQUAL "...")' instead of 'if ("${FOO}" STREQUAL "...")').
Agreed. Which is why I'd like to know how much code would actually need
to change (since upgrading code to use the new policy would make older
CMake versions do the wrong thing since they'll dereference the value
now). Would it be out of the question to allow the policy to *only* be
via the cmake_minimum_required() call and not manually to avoid such
issues?
> (Loosely related: if variable names were sane, it would at least be
> safe to write e.g. 'if ("#${FOO}" STREQUAL "#...")'. But alas,
> '#${FOO}' might still be the name of a variable.)
You could probably stick some sort of validator in front of the variable
map storage. I'd recommend also doing it on queries as an AUTHOR_WARNING
as well.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 16:00:08 -0500, Ben Boeckel wrote: > (since upgrading code to use the new policy would make older CMake > versions do the wrong thing since they'll dereference the value now). s/would/could/ --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 16:17:37 -0500, Matthew Woehlke wrote:
> Even without a branch, I'll risk stating that requiring 'if(FOO)' to
> become 'if(${FOO})' is not likely to go over well :-). (If nothing
> else, I'll go ahead and object to such a change.) Probably implicit
> expansion should be allowed anywhere the user doesn't think of the
> arguments as strings, e.g. if(LESS), if(VERSION_LESS), etc., i.e.
> everything *except* the string and regex flavors.
>From the if() docs, here's a grouping of what various predicates expect
along with my vote on whether it would make sense to do the implicit
dereference:
DEFINED
Variable name
COMMAND
POLICY
TARGET
CMake object-names
EXISTS
IS_NEWER_THAN
IS_DIRECTORY
IS_SYMLINK
IS_ABSOLUTE
Paths
LESS
GREATER
EQUALS
Numbers
MATCHES
STRLESS
STRGREATER
STREQUAL
Strings (even if the right side of MATCHES is interpreted)
VERSION_LESS
VERSION_EQUAL
VERSION_GREATER
Version strings
Other than , I don't really see a huge burden to not allowing
implicit dereferencing and it is more consistent at that point. In fact,
I'd be willing to say in that we *only* support implicit
dereference, but it may be too hard to detect:
if (${var})
and actually help users to fix such cases.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 16:37:51 -0500, Brad King wrote:
> IMO we should not be considering any change to implicit dereference
> in unquoted arguments. At most we should make if("FOO") not do it.
Any reason why? In my search of VTK and ParaView, there are lots of
places which use statements like:
if (${path} STREQUAL "string")
which would work just fine after killing implicit dereferences as well
and fights the principle of least surprise if ${path} is the name of a
variable. By far, the most popular implicit dereference intentional use
is "if (varname)" which is why I'd let that one go.
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Wed, Feb 19, 2014 at 17:40:45 +0100, Stephen Kelly wrote: > By the way, I have only started working on policy CMP0051, not CMP0052, so > if you want to take the CMP0052 spot, that would take pressure off me to > implement it. Do you mind re-numbering? Done locally. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 17:11:27 -0500, Brad King wrote:
> By limiting the change to quoted and bracket arguments we preserve
> existing behavior in common existing code but allow authors to protect
> themselves by quoting.
That also means I can't protect my code from things like:
set(evil "" STREQUAL bogus OR TRUE OR "")
if (PREFIX_${evil}_SUFFIX)
message("Evil prevails")
endif ()
by quoting the 'evil' expansion (these corner cases pop into my head
whenever I'm reading or thinking about quoting rules and such...I blame
writing a lot of shell code and being paranoid about things being safe).
--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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New EVIS parser moving forward (3.1)
On Fri, Feb 21, 2014 at 17:15:42 -0500, Ben Boeckel wrote: > On Wed, Feb 19, 2014 at 17:40:45 +0100, Stephen Kelly wrote: > > By the way, I have only started working on policy CMP0051, not CMP0052, so > > if you want to take the CMP0052 spot, that would take pressure off me to > > implement it. Do you mind re-numbering? > > Done locally. And merged to next for the nightlies to have a shot at it. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Recommendations for reducing spurious link dependencies?
On Fri, Feb 21, 2014 at 18:53:48 -0800, Dave Abrahams wrote: > I'm following up on this recent thread: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9324/focus=9330 > > Unfortunately, most of what was discussed there appears to involve advanced > CMake knowledge that I don't have. Would it be possible for someone to > look at the llvm/clang build and make some specific recommendations, > perhaps suggesting a procedure I could follow to winnow out the excess > dependencies? My usual process for this is to start with no linked libraries then add them in as needed. Detecting this involves writing a little tool which dlopen's all built shared libraries with RTLD_NOW and failing if symbols are missing. I have test cases which are automatically added for each shared library my builds generate to ensure that new dependencies are always satisfied. For a less time-intensive process, the --print-gc-sections and --gc-sections linker options may be of help. The --strip-unneeded option to strip(1) may help, but I doubt it. Maybe you could diff the nm -C output between the old and new libraries to see if any libraries were dropped? This[1] PDF states that ldd -u can help as well (but only shows unused direct dependencies). There is also a libaudit.so available on github which apparently can help as well (see the PDF for the URL and how to use it). For OS X, it appears[2] there is a -dead_strip_dylibs option which removes links to libraries which supply no used symbols. I don't know if it tells you when that happens. --Ben [1]http://elinux.org/images/6/6c/Elc2011_sankar.pdf [2]https://stackoverflow.com/questions/6687630/c-c-gcc-ld-remove-unused-symbols -- 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] Recommendations for reducing spurious link dependencies?
On Fri, Feb 21, 2014 at 19:59:44 -0800, Dave Abrahams wrote: > Thanks, but as far as I can tell, only static libraries are involved here Would it be possible to build them as shared for a one-time run? If not, you may be left with --gc-sections or removing all library linkings until you get no missing symbols in each library. --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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Custom Ninja deptypes
Hi, I just pushed dev/custom-ninja-deptypes to the stage. It allows a toolchain to specify an alternate deptype for Ninja by setting the variable CMAKE_NINJA_DEPTYPE_. It is done after the custom MSVC check since it requires other logic besides just changing the 'deps' Ninja rule variable. This is to preempt support for new depenency file formats upstream may support (I have the 'ldc' type as a pull request[1] currently). Since D is similar to Fortran (AFAIK) in the way that dependencies are handled (an object file for a single TU depends on many source files the compiler is best suited to determine at build time), this may be a way to get Fortran dependencies in Ninja as well. Looking at gfortran, it supports the -M depfile flags as of 4.6, so Ninja fortran support may just be a version check away (for gfortran at least). Other fortran compilers could get a depfile format supported in Ninja if they're something different. --Ben [1]https://github.com/martine/ninja/pull/721 -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] FindFoo.cmake and COMPONENTS
[ Sorry for stealing the thread, but this might help spawn off a follow-up patch for COMPONENT-handling docs. ] On Wed, Mar 26, 2014 at 19:02:40 +, Alex Merry wrote: > Modules that provide components are glossed over currently, despite > being difficult to implement correctly. Hmm, I wrote one recently[1] and it didn't seem *too* hard. What sort of hidden pitfalls are there? One I can think of (that isn't handled in that Find module) is dependencies between components. Thanks, --Ben [1]https://github.com/mathstuf/abagames-gunroar/blob/master/cmake/FindDerelict.cmake -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindFoo.cmake and COMPONENTS
On Wed, Mar 26, 2014 at 22:38:51 +, Alex Merry wrote:
> Actually, yeah, it's mainly the dependency handling that's hairy. There
> are couple of other things you have to be aware of; for instance, I've
> seen several find modules try to give all the components to
> pkg_check_modules() at once, but you can't do that (pkg_check_modules
> finds everything or nothing).
OK, good to know I'm not missing anything :) . My thought was to do the
following (in that linked module):
set(${component}_deps ...)
set(extra_deps)
foreach (component IN LISTS Derelict_FIND_COMPONENTS)
foreach (dep IN LISTS ${component}_deps)
# if dep not in Derelict_FIND_COMPONENTS
list(APPEND extra_deps "${component}")
endforeach ()
endforeach ()
and then to also search for the deps and finally do:
set(valid_components)
foreach (component IN LISTS Derelict_FIND_COMPONENTS)
set(missing)
foreach (dep IN LISTS ${component}_deps)
# if dep not found
list(APPEND missing "${component}")
endforeach ()
if (missing)
# if REQUIRED
# error out
else ()
# Add imported target.
list(APPEND valid_components "${component}")
endif ()
endforeach ()
foreach (component IN LISTS valid_components)
# Add dependency links here.
endforeach ()
This keeps the "find this component" logic free of any of the dependency
logic and falls back gracefully if components aren't found and such.
It is a little verbose though :( . If there were a nice way to do
callbacks[1] (to do the "find a component", "add the import target", and
"add the dependency link" bits), this would actually wrap up into a
module nicely.
--Ben
[1]I don't really like the "file(WRITE path); include(path)" route...
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] A little simplify Ninja code for linker commands
On Mon, Mar 31, 2014 at 00:40:02 +0200, Jiri Malak wrote: > I enclosed patch which a little simplify Ninja code for linker > commands. It removes redundant code for rule variable name and add > some temporary variables to improve code. Looks good to me. It passes all the tests on my machine. I've pushed it into next as 'simplify-ninja-linker-command'. --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake master slowdown in generation step
On Fri, Apr 04, 2014 at 17:13:12 +0200, Stephen Kelly wrote: > The Ninja generator was much slower than the Makefiles generator. I pushed > the optimize-source-file-processing topic with a commit which should fix the > major problem with Ninja. I'll see if there is more opportunity for > optimizing/caching though in general. Gah. This is on my huge stack of performance topics (which is getting stalled due to available time). Please look at: https://github.com/mathstuf/CMake/tree/dev/source-file-performance https://github.com/mathstuf/CMake/tree/dev/custom-target-performance What can be merged with those branches? --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake master slowdown in generation step
On Fri, Apr 04, 2014 at 15:04:50 -0400, Ben Boeckel wrote: > What can be merged with those branches? Looking at your branch closer, they look to be somewhat orthoganal, but there may be conflicts laying around. For anyone with *large* Ninja files, this branch may be worth a try as well: https://github.com/mathstuf/CMake/tree/dev/output-target-flags-once-in-ninja Some numbers for this last branch ($configure, $generate): Performance impact: paraview: (120.919, 123.944) → (121.292, 40.870) == (—, -67%) vtk: (32.413, 45.211) → (28.106, 15.736) == (-13%, -65%) webkit: (2.416, 30.074) → (2.148, 3.020) == (-11%, -90%) build.ninja size impact: paraview: 103M → 29M == -72% vtk: 63M → 21M == -67% webkit: 215M → 8.8M == -95% --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake master slowdown in generation step
On Sat, Apr 05, 2014 at 13:58:37 +0200, Stephen Kelly wrote: > I also looked at your local-speed-lang topic. testing/merge is the most recent. I really need to clean up the branch mess I've made (caused by attempting to merge two sets of work sessions between work and home without nuking things...usually by using 'local' as a prefix) :/ . > You found some c_str() calls > that can be removed in master, which I > didn't find with my clang tooling. Are you using ad-hoc tooling for > the commits in that topic too? vim+fugitive and :Ggrep. > You seem to have a lot of pending commits which I'd like to see in master at > some point, many of which are independent. Yeah; untangling the branch is a work-in-progress. --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] remove "x" placeholder from STREQUAL operands
On Thu, Apr 17, 2014 at 17:17:21 -0400, Matthew Woehlke wrote:
> set(" Linux" Windows) # succeeds
Even better:
set("
Linux" Windows)
> Alas, the only character that may not appear in a variable name is
> '\0'. (And even that is more due to use of raw char* with no length
> than intent, I bet.)
Actually, it's all std::string now, so you *could* use std::string(nuls,
len) to make one. But that means modifying the CMake code and shouldn't
be possible through CMakeLists.txt.
> I keep hoping that one of these days CMake would define valid
> identifiers as '[[:letter:]_][[:alnum:]_-]*'...
Make a policy for it. Watch the world burn :) . I also don't know where
you'd stick the validator without a decent performance hit (the regex
engine is not the best) :( . May as well stick the restriction on
function and macro names as well. Not that you could call any function
named in such a way, but better safe than sorry.
--Ben
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] remove "x" placeholder from STREQUAL operands
On Fri, Apr 18, 2014 at 10:06:36 -0400, Matthew Woehlke wrote: > Where a variable is created (e.g. the SET command), presumably. Internally-created variables would then be missed. string(TOUPPER "mystr" "varname with spaces") > I don't think the performance hit should be so bad if only writes are > checked, should it? Actually, I stuck a bloom filter in front of the definition map check to get a decent performance improvement (10%-20% depending on the project) on another branch. Using the loop which hashes to also check for valid characters might be possible. --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] generator expressions with variable
On Sat, Apr 19, 2014 at 12:08:42 +0200, Tim Blechmann wrote: > $<$>:-I$, > -I>> Does it work without the variable in there. (By the time the generator expression evaluator gets the string, it should be expanded.) > however evaluating the expression results in this command string: > $<1:-I$> Should that '$' be ','? Where did your literal ',' go from the above genex? --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On Tue, Apr 29, 2014 at 22:59:50 +0200, Alexander Neundorf wrote: > I was talking in general about these warnings. Typically some project > has a working build system (...otherwise it wouldn't build), and after > updating cmake, warnings appear. Since the build is working, there is > no immediate need (for the project) to change anything in the > buildsystem. The project will have an urgent need to change it once > the old behaviour is not supported anymore. CMake would like to drop old interfaces eventually (see 3.0 dropping pre-2.6 behaviors) and if anyone tries to build it on a distro 3 years from now, not having to dig out CMake 3.0 from the dustbin while CMake 3.10 (or 4.x) is current would be nice. At least CMake is warning on behavior changes, preserving previous behavior as an option (provided you don't just straight from 2.4.0 to 3.0), and providing examples of how to update things versus autotools where Fedora ships old versions due to projects never updating. Actually, should 3.0 warn about cmake_minimum_required(VERSION 2.4.0)? --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On Tue, Apr 29, 2014 at 22:31:27 -0400, Ben Boeckel wrote: > Actually, should 3.0 warn about cmake_minimum_required(VERSION 2.4.0)? Silly me; < 2.4.0 behavior is dropped and 2.2 does indeed warn. :) --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Weird dependency on object files generated elsewhere
On Thu, May 08, 2014 at 12:34:22 -0600, James Bigler wrote: > make[2]: *** No rule to make target > `src/CMakeFiles/cuda_compile.dir/cuda_compile_generated_test_bin.cu.o', > needed by `src/cuda_compile_example'. Stop. CMake generators will make paths relative to the build tree (I think it is to help reduce the generated output's size). > What I don't see in my makefiles is the build rule for the object file. That sounds like a bug. > I can provide a reproducer, but it would require having CUDA installed. Please provide it :) . Also, for the generation of the files, I don't think cuda would actually need to be there (`ln -s /usr/bin/true ~/bin/cuda` should get you at least that far). --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 15, 2014 at 12:45:27 +0200, Nicolas Desprès wrote: > Nope. These variables are the cmake equivalent to the __LINE__ and __FILE__ > C-pre-processor macro. What I need is the #line directive equivalent which > force the value of these variables so that error messages reported by cmake > uses the forced value. If you'd like to try a patch, the relevant code is in Source/cmExprParser*. Add a callback for #line nnn and update the CurrentLine variable cmExprParserHelper.cxx. Don't forget tests :) . This will also likely need a policy since there's no guarantee that #line "directives" don't exist in already existing code as comments. --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] What about #line like feature in cmake language?
On Thu, May 15, 2014 at 09:22:32 -0400, Brad King wrote: > I do not think the policy Ben mentioned will be needed. The syntax > > #line 1234 "/path/to/real/file" > > is fairly obscure and will be treated as a comment by older CMakes. My thought was that such rogue existing comments might give really unhelpful backtraces, but I do agree that it's probably rare enough to ignore if wanted (similar to foreach (IN LISTS)) since it does seem beneficial enough. --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Any plans to remove the limitation in command line length for the cmake -E remove command?
On Thu, May 15, 2014 at 13:23:10 -0700, Alan W. Irwin wrote:
> I have recently been reminded that the "cmake -E remove" command has a
> limitation due to the length of command line that is acceptable to
> whatever shell is being used. Is there any willingness to remove that
> limitation (in which case it would be worthwhile for me to make a
> formal bug report) or is this limitation something that should just be
> accepted indefinitely?
This isn't limited to "cmake -E remove". The problem is that the line is
too long to even call "cmake -E remove", so no amount of code on CMake's
side will help here. Well, /technically/ it could, but then you need
some way of doing:
add_custom_command(
TARGET clean-testfiles
BASE_COMMAND cmake -E remove
ARGUMENTS${test_output_files_LIST})
and then have CMake implement something like xargs to chunk the
available arguments out. I don't think the extra complexity is worth it,
IMO. Possible solutions I can think of follow.
> The reason I ask is the PLplot test suite has a combinatorial issue
> with the number of different tests that are possible. As currently
> implemented we are careful not to explore all combinations of the
> possibilities in our testing. Nevertheless, the typical result of
> ctest is ~5000 files which consume ~3GB of disk space. Therefore, I
> have implemented a convenience custom target to remove all those files
> as follows:
Would it make more sense to have tests delete their outputs unless they
fail or KEEP_TEST_FILES environment variable is set (which would then be
run on a subset of tests ideally)? This is what VTK does.
> add_custom_target(clean_ctest_plot_files
>COMMAND ${CMAKE_COMMAND} -E remove ${test_output_files_LIST}
>WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
>)
Alternatively (with caveats in Ninja; see below):
add_custom_target(clean_ctest_plot_files)
foreach (test_file IN LISTS test_output_files_LIST)
add_custom_command(
TARGET clean_ctest_plot_files
COMMAND cmake -E remove "${test_file}")
endforeach ()
This is probably fine in makefiles (which I believe is one line per
command on a target), but will fail with ninja though (since it joins
all commands with " && " and runs in one shell). I don't know about the
IDE generators.
Ninja would be fine with your add_custom_target if you set
CMAKE_NINJA_FORCE_RESPONSE_FILE to TRUE though.
--Ben
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Any plans to remove the limitation in command line length for the cmake -E remove command?
On Thu, May 15, 2014 at 23:52:18 -0700, Alan W. Irwin wrote: > Just in case I run into command-length limitations for the cmd > environment in other contexts that cannot be solved so neatly, I am > also wondering if cmd has a general mechanism (e.g., reading from a > file) to work around its severe command-length limitations. And if > so, could the COMMAND implementation be changed to use that mechanism > behind the scenes when the cmd environment is detected without > changing the add_custom_command or add_custom_target syntax in the > slightest? Not everything supports response files (it's usually compilers and MS tools). One thing we could do is detect when an add_custom_command or add_custom_target might run foul of command line length limits and warn for it. I don't know what else we could do without teaching CMake about every command's semantics. I suppose we could add response file wrappers around all long command lines, but command line parsing on Windows can be 100% custom, so there might need problems there :/ . --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New no-soname-option topic for e.g. Android
On Wed, May 28, 2014 at 10:39:22 +0200, Nils Gladitz wrote: > As discussed here http://www.cmake.org/pipermail/cmake/2014-May/057657.html > I proposed a minor modification in CMake that would allow shared library > targets to always be linked by -l/-L options rather than full pathname > on platforms which do not support SONAMEs. > > I remember there being discussions on adding support for Android as a > platform. > If anyone is still working on it this topic might already be superfluous > so I haven't merged it yet. I have some Android work at home and I remember setting up Android to *have* a SONAME so that things worked properly (there were weird errors otherwise). I'll have to look into where things broke without it, but I won't get a chance until Tuesday. --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New no-soname-option topic for e.g. Android
On Wed, May 28, 2014 at 16:57:28 +0200, Nils Gladitz wrote: > I assumed that because people kept removing the soname options for their > Android toolchains that SONAMEs aren't supported at all. No idea. > It however looks like they just can't have versioned names. > Perhaps ignoring the VERSION/SOVERSION properties would suffice since > the default SONAME should work which would make this topic superfluous > at least for android. > It sounds like you probably already have all of that covered. Here's the commit which added it to my working branch: https://github.com/mathstuf/CMake/commit/d4a2a23b9d500434e294ad2b8515731aeaee7c30 For the lazy, the commit message: Android: Support sonames on Android This is actually required because without it, the APK will be bundle up any library linking to a library without a SONAME with an absolute path. I don't know about SOVERSION; the project I'm using it with[1] isn't using it. --Ben [1]https://github.com/mathstuf/abagames-gunroar -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiler features/extensions remaining/future issues
On Sat, May 31, 2014 at 15:17:59 +0200, Stephen Kelly wrote: > Here is a dump of some notes I have accumulated regarding compile features. I haven't read this thoroughly, just enough to see that this item is missing: 9) Performance I'm seeing considerable performance impact of this feature, even when it isn't used: [ Snipping out slower runs (of 3); full file available. All runs were made with CMP0053 set to NEW, so configure times are mainly due to the new parser improvements. ] Running cmake build 3.0.0rc6 from cmake-3.0.0rc6... Running tests for paraview... Running make test 1... XX Timing of configure: 29.782 XX Timing of generate: 19.9902 Running ninja test 2... XX Timing of configure: 29.4229 XX Timing of generate: 37.4056 Running tests for vtk... Running make test 1... XX Timing of configure: 14.0793 XX Timing of generate: 8.14633 Running ninja test 1... XX Timing of configure: 13.9817 XX Timing of generate: 12.9389 Running tests for slicer... Running make test 2... XX Timing of configure: 9.77397 XX Timing of generate: 31.0064 Running ninja test 2... XX Timing of configure: 9.91163 XX Timing of generate: 40.8335 Running tests for sprokit... Running make test 3... XX Timing of configure: 2.9694 XX Timing of generate: 2.87538 Running ninja test 1... XX Timing of configure: 3.01635 XX Timing of generate: 0.572799 versus: Running cmake build master from cmake-master... Running tests for paraview... Running make test 3... XX Timing of configure: 21.5985 XX Timing of generate: 35.5566 Running ninja test 2... XX Timing of configure: 22.0632 XX Timing of generate: 59.1115 Running tests for vtk... Running make test 3... XX Timing of configure: 11.2056 XX Timing of generate: 10.4012 Running ninja test 3... XX Timing of configure: 10.8211 XX Timing of generate: 14.5732 Running tests for slicer... Running make test 3... XX Timing of configure: 7.48876 XX Timing of generate: 52.8917 Running ninja test 1... XX Timing of configure: 7.31795 XX Timing of generate: 62.4773 Running tests for sprokit... Running make test 2... XX Timing of configure: 3.28055 XX Timing of generate: 3.44212 Running ninja test 2... XX Timing of configure: 3.32206 XX Timing of generate: 1.22392 with my performance branches on master: Running cmake build merge from cmake-merge... Running tests for paraview... Running make test 3... XX Timing of configure: 19.9036 XX Timing of generate: 30.26 Running ninja test 1... XX Timing of configure: 19.1339 XX Timing of generate: 27.0993 Running tests for vtk... Running make test 2... XX Timing of configure: 8.63752 XX Timing of generate: 9.45069 Running ninja test 3... XX Timing of configure: 8.81416 XX Timing of generate: 7.74161 Running tests for slicer... Running make test 2... XX Timing of configure: 6.75249 XX Timing of generate: 44.8809 Running ninja test 2... XX Timing of configure: 6.58756 XX Timing of generate: 38.2476 Running tests for sprokit... Running make test 2... XX Timing of configure: 1.7703 XX Timing of generate: 2.57902 Running ninja test 3... XX Timing of configure: 1.81398 XX Timing of generate: 0.441557 Which shows that my branches help ninja quite a bit (which makes sense since that's been my focus so far), but now make is showing regressions (which ninja probably shares) which were not helped nearly as much. Looking at callgrind output[1], I'd say that compile features are a non-trivial amount (10% of /total/ time; same as compile options) of the added time especially considering that the projects aren't using compile features at all. Thanks, --Ben [1]The code run was next + my branches. -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiler features/extensions remaining/future issues
On Mon, Jun 09, 2014 at 07:46:42 -0400, David Cole wrote: > Ben, can you provide a script that assumes nothing but a CMake install > to download a project and demonstrate the problem? Attached. Run as: ./test-cmake.sh [...] the first argument defaults to /usr. All of my tests are done with reconfigures, not initial configures, so cmake is run twice and the second run's timing is used. --Ben cmake-test.sh Description: Bourne shell script -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiler features/extensions remaining/future issues
On Mon, Jun 09, 2014 at 07:46:42 -0400, David Cole wrote: > > Can you create an sscce? Not really. The wall time impact is only really visible on sizeable projects and the jitter in the time can be masked in smaller projects. The smallest you're probably going to get is VTK without searching for projects. Other projects which might be of interest to test for performance impact would be the larger KDE projects (at least kdelibs, kde-workspace, and KDevelop are likely), and LLVM. > Sounds like just downloading ParaView, ITK or Slicer, and configuring > it with CMake is the reproduce case. How much simpler and more > stand-alone do you want it to be? Specifically, ParaView should have Python bindings enabled. I haven't tested ITK and Slicer is the Slicer-build directory inside of the slicer superbuild (which you get by default from the source tree). --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] add_compile_options and link flags
Hi,
So add_compile_options exists now, but is still not a 100% replacement
for CMAKE_CXX_FLAGS_${config} because the flags are only used for the
.c -> .o step and not for linking. Some flags need to be passed to the
linker as well (in my case, profiling flags, but I imagine other tooling
flags, standards, and probably LTO need to be passed consistently). Are
there plans for an add_link_options (or add_link_flags) command as well?
Thanks,
--Ben
--
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiler features/extensions remaining/future issues
On Tue, Jun 10, 2014 at 17:30:24 +0200, Stephen Kelly wrote: > I want to avoid having to understand all of the ParaView CMake code and that > of its dependencies, and whether python bindings need to be enabled etc. Well, there isn't much you need to grok from the code there; it's just a project with lots of targets with lots of interdependencies. When adding compile features, the time drops noticeably. Brad, Rob, and I looked at the code and performance output today and it looks like it is the evaluation of the generator expressions made to find the compile features, compile options, and compile definitions that takes a long time. *Each* takes ~10% of overall time and the projects I'm testing don't use the interface propagation features *at all*. It's the evaluation of the generated genex that takes a long time (parsing is now inconsequential). Using debugging messages shows that the evaluations are being cached, but that probably only saves us from even more slowdowns. Brad is going to take a deeper look at it and might have more information in the next few days. > Ben, can you run your timing test with a commit before my topic and after > it? Timing tests with master and your extra topics don't tell us anything on > this question. Will do. Should be done in an hour or two. I'm using commits b56a9ae (before) and 593b69c (after): commit b56a9ae7f14189fd2bce2ca3e9441060ca231638 Merge: 593b69c 9eaf375 Author: Brad King Date: Tue Apr 15 10:32:11 2014 -0400 Merge topic 'target_compile_features' 9eaf3755 Export: Populate INTERFACE_COMPILE_FEATURES property. 8ed59fc2 Add target_compile_features command. 4e6ca504 cmTargetPropCommandBase: Change the interface to return bool. 5412dede cmTarget: Transitively evaluate compiler features. baff4434 cmTarget: Allow populating COMPILE_FEATURES using generator expressions. f97bf437 Features: Add cxx_auto_type. 03355d6b cmTarget: Add COMPILE_FEATURES target property. faeddf64 project: Add infrastructure for recording CXX compiler features 913394af cmTarget: Add CXX_STANDARD and CXX_EXTENSION target properties. 8238a6cd Add some COMPILE_OPTIONS for specifying C++ dialect. 892243fc Tests: Require CMake 3.0 for the SystemInformation test. 59b5fdd3 Don't load Clang-CXX from AppleClang-CXX. commit 593b69c9dc9e692b198f1ddbf9251130e61a4679 Merge: 33358fd 941a140 Author: Brad King Date: Tue Apr 15 10:22:41 2014 -0400 Merge topic 'aix-no-sstream' 941a1404 AIX: fix compilation error because of missing --Ben -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiler features/extensions remaining/future issues
On Tue, Jun 10, 2014 at 13:17:57 -0400, Ben Boeckel wrote: > Will do. Should be done in an hour or two. I'm using commits b56a9ae (before) > and 593b69c (after): Attached. --Ben Running cmake build after-features from cmake-after-features... Running tests for paraview... Running make test 1... XX Timing of configure: 28.4797 XX Timing of generate: 39.1605 Running make test 2... XX Timing of configure: 28.0603 XX Timing of generate: 39.6021 Running make test 3... XX Timing of configure: 28.1262 XX Timing of generate: 39.3873 Running ninja test 1... XX Timing of configure: 28.1178 XX Timing of generate: 71.5787 Running ninja test 2... XX Timing of configure: 28.2574 XX Timing of generate: 70.8935 Running ninja test 3... XX Timing of configure: 28.9053 XX Timing of generate: 70.6467 Running tests for slicer... Running make test 1... XX Timing of configure: 9.53432 XX Timing of generate: 62.4838 Running make test 2... XX Timing of configure: 9.3675 XX Timing of generate: 62.4657 Running make test 3... XX Timing of configure: 9.35078 XX Timing of generate: 62.2783 Running ninja test 1... XX Timing of configure: 9.44152 XX Timing of generate: 74.656 Running ninja test 2... XX Timing of configure: 9.28958 XX Timing of generate: 74.7592 Running ninja test 3... XX Timing of configure: 9.33024 XX Timing of generate: 75.25 Running tests for sprokit... Running make test 1... XX Timing of configure: 3.01892 XX Timing of generate: 3.59591 Running make test 2... XX Timing of configure: 2.9013 XX Timing of generate: 3.44985 Running make test 3... XX Timing of configure: 2.96652 XX Timing of generate: 3.48186 Running ninja test 1... XX Timing of configure: 3.01794 XX Timing of generate: 1.20835 Running ninja test 2... XX Timing of configure: 2.95976 XX Timing of generate: 1.19672 Running ninja test 3... XX Timing of configure: 2.95632 XX Timing of generate: 1.19099 Running cmake build before-features from cmake-before-features... Running tests for paraview... Running make test 1... XX Timing of configure: 28.6817 XX Timing of generate: 35.5692 Running make test 2... XX Timing of configure: 28.3886 XX Timing of generate: 35.6613 Running make test 3... XX Timing of configure: 28.0809 XX Timing of generate: 35.6549 Running ninja test 1... XX Timing of configure: 28.1364 XX Timing of generate: 67.8352 Running ninja test 2... XX Timing of configure: 28.2551 XX Timing of generate: 67.2962 Running ninja test 3... XX Timing of configure: 28.7813 XX Timing of generate: 66.6906 Running tests for slicer... Running make test 1... XX Timing of configure: 8.91568 XX Timing of generate: 54.8089 Running make test 2... XX Timing of configure: 9.00928 XX Timing of generate: 54.9421 Running make test 3... XX Timing of configure: 8.93402 XX Timing of generate: 54.8247 Running ninja test 1... XX Timing of configure: 8.89655 XX Timing of generate: 67.4797 Running ninja test 2... XX Timing of configure: 8.90781 XX Timing of generate: 67.2723 Running ninja test 3... XX Timing of configure: 8.98565 XX Timing of generate: 67.2085 Running tests for sprokit... Running make test 1... XX Timing of configure: 3.00015 XX Timing of generate: 3.65421 Running make test 2... XX Timing of configure: 2.94023 XX Timing of generate: 3.4586 Running make test 3... XX Timing of configure: 2.87959 XX Timing of generate: 3.43462 Running ninja test 1... XX Timing of configure: 3.40615 XX Timing of generate: 1.28768 Running ninja test 2... XX Timing of configure: 2.91383 XX Timing of generate: 1.18895 Running ninja test 3... XX Timing of configure: 2.94707 XX Timing of generate: 1.19735 -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cost of usage requirements (was: Compiler features/extensions remaining/future issues)
On Wed, Jun 11, 2014 at 10:46:52 -0400, Brad King wrote: > However, please look at improving the implementation to have > something under O(n^2) complexity when the usage requirements > do not actually depend on the headTarget. I've added a branch on stage which contains a test for cmake's big-O order in the number of targets. I'm not merging it yet, but if anyone wants to test with it, feel free. linear-target-test Please note that on a Core i7 @ 3.4 GHz the test currently takes 1100+ seconds. Feel free to remove the higher-end test cases to make the wait easier. Unfortunately, the number of points is low, so the correlation can be high while it looks obviously non-linear[1], so don't remove too many. --Ben [1]https://bit.ly/1jl6IYt r² == 0.82 -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Clang 3.5-svn emmits tautological-pointer-compare warning
On Fri, Jun 20, 2014 at 10:02:43 +0200, Christoph Grüninger wrote: > Find attached a patch the removes the condition that is always true. > Maybe you want to keep the condition as an assert? Hmm. I don't see anything in the docs which states that uname must always have non-NULL in 'release'. Maybe clang is using extra information from the implementation of uname (which may be a macro)? It is under a __linux defined block, so maybe if uname was guaranteed to be non-NULL for Linux at least, it'd be acceptable IMO. --Ben -- 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
Re: [cmake-developers] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
On Tue, Jun 24, 2014 at 14:21:37 -0400, Brad King wrote:
> On 06/24/2014 08:31 AM, Mojca Miklavec wrote:
> > /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script
> > CMakeFiles/CMakeLib.dir/link.txt --verbose=1
> >
> > isn't outputting the whole command, but cutting it in the middle instead.
>
> The lines are read here:
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmcmd.cxx;hb=v3.0.0#l988
>
> using the GetLineFromStream helper:
>
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;hb=v3.0.0#l4157
>
> Note the buffer size is 1024. Something must go wrong with the
> stream state to make it look like EOL or EOF to this code.
The proper way to read lines from a file using iostream is:
std::string line;
while (std::getline(istr, line)) {
// use line
}
Unfortunately, it looks like there's unavoidable extra logic in there.
Maybe we could do:
#ifdef BROKEN_STREAMS
// crutch code
#else
// sanity
#endif
--Ben
--
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
Re: [cmake-developers] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)
On Tue, Jun 24, 2014 at 15:23:32 -0400, Brad King wrote: > If that actually worked on all old stream libraries then we would > not need GetLineFromStream. Also GetLineFromStream has a separate > output argument for indicating whether the line ended in a newline. The newline parameter isn't hard to reproduce (just use istr.eof() right after the getline() succeeds), but the sizeLimit parameter is harder :( . We could hack it up with a custom max_size() method on a custom std::basic_string subclass, but that sounds awful. > Yes, please try this. Mojca, how did you bootstrap cmake to use libc++ and clang? CXX="clang++ -stdlib=libc++"? I probably won't get to it until Thursday though. --Ben -- 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
Re: [cmake-developers] IMPORTED targets for some Find modules
On Wed, Jun 25, 2014 at 16:21:20 +0200, Stephen Kelly wrote: > The 'obvious' name for such a variable would be > > Boost_DISABLE_NO_AUTOLINKING > > but I used a name which avoids double-negation. Could it just be called Boost_ENABLE_AUTOLINKING and avoid negations altogether? --Ben -- 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
Re: [cmake-developers] [RFC] ctest: do not output "failed" when no tests failed
On Wed, Jun 25, 2014 at 11:17:22 -0400, Brad King wrote: > -100% tests passed, 0 tests failed out of 1 > +All 1 tests passed What about using color for a non-zero number of failed tests? --Ben -- 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
Re: [cmake-developers] Remove check for source files in add_library()
On Fri, Jun 27, 2014 at 15:48:34 +0200, Ådne Hovda wrote: > It would be handy when creating macros that wraps add_library where the > number of source files is unknown to be able to write: > > add_library( mylib ) > target_sources( mylib PRIVATE mylib.c mylib.h ) > > but this fails with the warning "You have called ADD_LIBRARY for library > testlib without any source files. This typically indicates a problem > with your CMakeLists.txt file" Why not just defer the add_library until the end of the file? > I have tried to just remove that check in cmAddLibraryCommand and apart > from a warning about missing LINKER_LANGUAGE it works okay. > > https://github.com/aadnehovda/CMake/commit/d527b1db787c426517f7af357df0cd3ba9d9a12a > > I guess there are other implications I have not though of as well? Does the test suite run without complaint? Also, a test for this would be appreciated. --Ben -- 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
Re: [cmake-developers] [RFCv2] ctest: color test summary output
On Tue, Jul 01, 2014 at 16:01:48 -0400, Steve Dougherty wrote: > When I glance at ctest output, even if all tests passed, my eye catches > "failed" before noticing the other things, which gives me a start. > > To make this less likely to happen this colors the test summary green > if all tests succeeded and red if not. > > Although I have attempted to edit the test regular expressions so that > they still pass, I'm missing something about matching escape codes, > and a third of them fail. From LastTest.log: Colors should only be output if we're outputting to a TTY. Pipes or redirections should not be colored (they'll only confuse those who don't recognize the escape sequences). CMake also has color routines already, but I don't know off-hand how accessible they are from CTest code (i.e., might be static functions). --Ben -- 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
Re: [cmake-developers] [patch] install cfbundles as directory
On Wed, Jul 09, 2014 at 11:09:01 -0400, Brad King wrote:
> > + std::string targetNameBase = targetName.substr(0,
> > targetName.find_first_of("/"));
Not that this is performance-sensitive region, but in the pursuit
removing bad patterns to avoid copy/paste issues in the future:
std::string targetNameBase = targetName.resize(targetName.find('/'));
is better, though the resize might not be doable since there's a check
for npos that is necessary if the targetName doesn't have a slash in it.
The find_first_of(one_char_string) should definitely be find(one_char)
or find_first_of(one_char).
Of course, assuming this line survives to the final patch.
Thanks,
--Ben
--
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
Re: [cmake-developers] [patch] fix Info.plist parser
On Thu, Aug 07, 2014 at 19:36:54 +0200, Tim Blechmann wrote:
> diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
> index b896de2..60d01b5 100644
> --- a/Modules/BundleUtilities.cmake
> +++ b/Modules/BundleUtilities.cmake
> @@ -237,6 +237,7 @@ function(get_bundle_main_executable bundle result_var)
> file(READ "${bundle}/Contents/Info.plist" info_plist)
> string(REGEX REPLACE ";" ";" info_plist "${info_plist}")
> string(REGEX REPLACE "\n" "${eol_char};" info_plist "${info_plist}")
> +string(REGEX REPLACE "\r" "${eol_char};" info_plist "${info_plist}")
Do these need to be REGEX REPLACE? Any problem with straight REPLACE?
--Ben
--
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
Re: [cmake-developers] Preparing for CMake 3.1.0-rc1
On Fri, Oct 03, 2014 at 08:27:56 -0400, Brad King wrote: > In preparation for the first 3.1 release candidate I will feature- > freeze master as of 2014-10-09. As of now there are several open > topics in 'next' that we should try to land in master by then, but > please refrain from adding non-trivial changes in the meantime. I've just added the ubsan-support branch to stage (not merged yet; no new tests). It contains some documentation updates for AddressSanitizer and MEMORYCHECK_TYPE which were missed as well as support for MemoryCheckSanitizerOptions which adds key/value values to the environment variables for the sanitizers (ASAN_OPTIONS, TSAN_OPTIONS, and UBSAN_OPTIONS). Feel free to cherry-pick the documentation fixes (or I can spin out a branch) if the other changes are too late (I hope to add tests Monday, but can do it today if that's too late). --Ben -- 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
Re: [cmake-developers] Preparing for CMake 3.1.0-rc1
On Fri, Oct 03, 2014 at 13:51:54 -0400, Ben Boeckel wrote: > Feel free to cherry-pick the documentation fixes (or I can spin out a > branch) if the other changes are too late (I hope to add tests Monday, > but can do it today if that's too late). A test has been added. Brad, there are some bugfixes for tsan and asan in there. Is it too late to merge the whole branch or do you want me to cherry-pick them out? --Ben -- 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
Re: [cmake-developers] Preparing for CMake 3.1.0-rc1
On Mon, Oct 06, 2014 at 14:31:58 -0400, Brad King wrote: > Please re-order the topic to have all the fixes first, and then the > changes to add ubsan support. That way I can revert the latter if > it is problematic. Then merge the whole topic for testing. Done. --Ben -- 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
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
On Fri, Oct 10, 2014 at 17:59:07 +0400, Ruslan Baratov via cmake-developers wrote: > > Behavior when there's a lock that still exists (by bug/mistake) after > > CMake is done running is going to be strange and possibly > > hard-to-diagnose / hard-to-understand. > That's *exactly* the problem I have and why I start this discussion. > Currently I'm using mkdir command which return 0 only if directory > created by current process (just to clarify, not the cmake -E > make_directory). This works fine for me (tested on windows (mingw, > cygwin), linux and mac). But I can't (or I don't know how) make remove > this directory when I Ctrl+C my build (or abort the job on jenkins > server). My current implementation just keep spinning with message: > "Directory locked by cmake, build started in directory > at ". Maybe we need something like the 'trap' shell builtin which runs code on various triggers rather than something like file/directory locks which are…hairy (especially in the face of things like NFS or Samba)? I can think of at least: - end of configure - end of generate - end of directory scope - end of scope (function or directory) --Ben -- 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
Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible
On Fri, Oct 03, 2014 at 20:00:00 +0200, Sylvain Joubert wrote: > Unlike the rerun target which is manually added by the Ninja generator, > the install and package targets are handled in a generic way by the > utility target generator. > > Thus, handling these targets is not as straightforward as rerun. > I'll keep digging a bit, maybe I can find a way to do it. ;-) It should be possible to set a property on the target(s) when they are created. Though…looking at the docs, it seems that there's no generic JOB_POOL property for custom targets. When that property is implemented, setting 'console' for these targets for Ninja should be simple enough. --Ben -- 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
Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch
[ Adding Ben Cooksley to the CC list; feel free to reply privately and I'll forward to the list if you keep getting rejected from it. ] Hi, > > It would appear that CMake 3.0 to 3.1 introduces a colossal change in > > behaviour. This change totally breaks all KDE projects which use > > Extra-CMake-Modules, as necessary headers are no longer installed. This is indeed true (between the new variable expansion code (CMP0053) and 'if()' variable expansion rules (CMP0054), there's a lot of changes otherwise); however, all you should get are warnings about the change, not the actual behavior change without actually bumping your minimum version or enabling the policy explicitly. > > This has become an issue following http://build.kde.org/job/cmake/160/ > > which has led to a significant number of our projects failing to build > > from source as can be seen here - > > http://build.kde.org/view/Frameworks/ So looking at kdelibs4support, I see lots of CMP0053 warnings (due to the @var@ expansion in normal CMakeLists.txt processing which was obscure and undocumented) and CMP0048 warnings (I'm not familiar with it, but it's about project() offering version variables). In kdelibs, I see CMP0022 and CMP0046 warnings (both related to target_link_libraries and things which are likely bugs anyways such as depending on non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and LINK_INTERFACE_LIBRARIES). However, I do see: 04:35:39 -- Installing: /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h in kdelibs' logs, so it makes me think that: /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: fatal error: kpluginfactory.h: No such file or directory implies the build isn't getting the include directories plumbed through properly. I'll try a build tomorrow (or if it'd be possible to run a Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great too since the environment would be consistent then). My gut feeling is some CMP0054 corner case isn't caught and falls through to the new behavior without a warning (or the old behavior was subtly changed in the process), but that's just a shot in the dark. > > Someone needs to investigate this before CMake 3.1.0 goes out the door > > and fix it. I've no idea what the policy is in the CMake world, but in > > the KDE world this sort of compatibility breakage would be a release > > blocker. Thanks for testing the rc; it should be a blocker on our side too. It would indeed be bad for 3.1.0 to release with such breaking changes. We try really hard for backwards compatibility. Obviously our test coverage is lacking somewhere. > And it would seem that the CMake developers prefer to live in their > own closed off little bubble. My post was automatically rejected. > Someone who is subscribed there will have to take this up with them. > I'm extremely displeased. > > If they release CMake 3.1.0 with this regression, we should consider > forking CMake as their developers can't be trusted to ensure our code > remains buildable. For preventing this in the future, would it be possible to set up Jenkins build to submit builds for kdelibs and a few other libraries which would test CMake master and submit to CMake's dashboard some results nightly so we can catch these problems more quickly? There are examples in: https://github.com/Kitware/CMake/tree/master/Tests/Contracts for how this is done for other projects already. The instance would then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run CMake's test suite and submit to the dashboard. Thanks, --Ben -- 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-developers] [bcooks...@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]
[ Forward from Ben Cooksley. ] - Forwarded message from Ben Cooksley - Date: Fri, 24 Oct 2014 19:55:23 +1300 From: Ben Cooksley To: ben.boec...@kitware.com Cc: Bill Hoffman , "cmake-developers@cmake.org" Subject: Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch On Fri, Oct 24, 2014 at 3:34 PM, Ben Boeckel wrote: > [ Adding Ben Cooksley to the CC list; feel free to reply privately and > I'll forward to the list if you keep getting rejected from it. ] Duly noted, will do. > > Hi, Hi, > >> > It would appear that CMake 3.0 to 3.1 introduces a colossal change in >> > behaviour. This change totally breaks all KDE projects which use >> > Extra-CMake-Modules, as necessary headers are no longer installed. > > This is indeed true (between the new variable expansion code (CMP0053) > and 'if()' variable expansion rules (CMP0054), there's a lot of > changes otherwise); however, all you should get are warnings about the > change, not the actual behavior change without actually bumping your > minimum version or enabling the policy explicitly. Oki, that sounds about right. > >> > This has become an issue following http://build.kde.org/job/cmake/160/ >> > which has led to a significant number of our projects failing to build >> > from source as can be seen here - >> > http://build.kde.org/view/Frameworks/ > > So looking at kdelibs4support, I see lots of CMP0053 warnings (due to > the @var@ expansion in normal CMakeLists.txt processing which was > obscure and undocumented) and CMP0048 warnings (I'm not familiar with > it, but it's about project() offering version variables). In kdelibs, I > see CMP0022 and CMP0046 warnings (both related to target_link_libraries > and things which are likely bugs anyways such as depending on > non-existent targets or a mismatch between INTERFACE_LINK_LIBRARIES and > LINK_INTERFACE_LIBRARIES). > > However, I do see: > > 04:35:39 -- Installing: > /srv/jenkins/workspace/kdelibs_master/local-inst/srv/jenkins/install/linux/x86_64/g++/latest-qt4/kde/kdelibs/inst/include/kpluginfactory.h > > in kdelibs' logs, so it makes me think that: > > > /srv/jenkins/workspace/kdelibs4support_master_qt5/src/kssl/kcm/kcmssl.cpp:27:28: > fatal error: kpluginfactory.h: No such file or directory > > implies the build isn't getting the include directories plumbed through > properly. I'll try a build tomorrow (or if it'd be possible to run a > Jenkins build of kdelibs4support with make VERBOSE=1, that'd be great > too since the environment would be consistent then). My gut feeling is > some CMP0054 corner case isn't caught and falls through to the new > behavior without a warning (or the old behavior was subtly changed in > the process), but that's just a shot in the dark. Slight bit of confusion here, sorry about that. kdelibs_master is for the KDE 4 (Qt 4 based) series of software. kdelibs4support_master_qt5 is for the Frameworks 5 (Qt 5 based) series of software. In this case, kpluginfactory.h should come from kcoreaddons. It's build log can be found here - http://build.kde.org/job/kcoreaddons_master_qt5/153/consoleText I can't see a sign of kpluginfactory.h being installed there unfortunately. Others have done a bit of digging already it seems as to what might be the cause. Please see https://mail.kde.org/pipermail/kde-frameworks-devel/2014-October/019906.html for that. If you're still interested in a VERBOSE=1 build of some of our projects, i'll be more than happy to supply such a log. > >> > Someone needs to investigate this before CMake 3.1.0 goes out the door >> > and fix it. I've no idea what the policy is in the CMake world, but in >> > the KDE world this sort of compatibility breakage would be a release >> > blocker. > > Thanks for testing the rc; it should be a blocker on our side too. It > would indeed be bad for 3.1.0 to release with such breaking changes. > We try really hard for backwards compatibility. Obviously our test > coverage is lacking somewhere. That is a relief to know. > >> And it would seem that the CMake developers prefer to live in their >> own closed off little bubble. My post was automatically rejected. >> Someone who is subscribed there will have to take this up with them. >> I'm extremely displeased. >> >> If they release CMake 3.1.0 with this regression, we should consider >> forking CMake as their developers can't be trusted to ensure our code >> remains buildable. Sorry for that - I got a bit caught up in the heat of the moment. > > For preventing this in the future, would it be po
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote:
> On Friday 24 October 2014 10:20:42 Brad King wrote:
> > On 10/24/2014 10:02 AM, Brad King wrote:
> > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
> > > Author: Ben Boeckel
> > > Date: Wed Mar 12 14:01:45 2014 -0400
> > >
> > > cmDefinitions: Don't store parent lookups
> > >
> > > When looking up scopes, it is faster to not store the lookup locally
> > > to
> > > keep the maps smaller and avoid extra allocations and rebalancing.
So the problem was that when redoing the "pull" logic for PARENT_SCOPE,
it was unconditional when it should be skipped if the variable is
already local.
Pushed to stage as:
variable-pull-failure
> ---
> cmake_minimum_required(VERSION 3.0)
> project(Minimal NONE)
>
> function(test_set)
> set(blah "value2")
> message(STATUS "before PARENT_SCOPE blah=${blah}")
> set(blah ${blah} PARENT_SCOPE)
> message(STATUS "after PARENT_SCOPE blah=${blah}")
> endfunction()
>
> set(blah value1)
> test_set()
> message(FATAL_ERROR "in parent scope, blah=${blah}")
> --
Now added as a test in CMake (with minor changes).
Thanks,
--Ben
--
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
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 10:54:17 -0400, Ben Boeckel wrote: > On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote: > > On Friday 24 October 2014 10:20:42 Brad King wrote: > > > On 10/24/2014 10:02 AM, Brad King wrote: > > > > commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 > > > > Author: Ben Boeckel > > > > Date: Wed Mar 12 14:01:45 2014 -0400 > > > > > > > > cmDefinitions: Don't store parent lookups > > > > > > > > When looking up scopes, it is faster to not store the lookup locally > > > > to > > > > keep the maps smaller and avoid extra allocations and rebalancing. > > So the problem was that when redoing the "pull" logic for PARENT_SCOPE, > it was unconditional when it should be skipped if the variable is > already local. So after discussion with Brad, this commit breaks other subtle behaviors as well, so the plan is to just revert it instead and defer its optimizations until after 3.1 once proper tests are in place (more under development now). --Ben -- 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
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 11:36:40 -0400, Ben Boeckel wrote: > So after discussion with Brad, this commit breaks other subtle behaviors > as well, so the plan is to just revert it instead and defer its > optimizations until after 3.1 once proper tests are in place (more under > development now). There are two branches on stage now (the previously mentioned branch has been reverted): - parent-scope-tests Based on v3.0.0~ to test that it worked on the release. This includes the more complex testing of PARENT_SCOPE's behaviors. - revert-definition-map-lookup Based on the bad commit, this reverts it with a description of what it is happening and then merges in parent-scope-tests to ensure that it works there. --Ben -- 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
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: > On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly wrote: > > Is build.kde.org now using the release branch of cmake.git instead of the > > next branch? When/why did that change? > > This was changed around about > http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html > The motivation behind the change was to get the CI system to have the > same setup as developers I think, and to avoid regressions in 3.1 > which had been causing some build problems at the time. Those same > regressions are the ones causing us issues now. > > Interestingly, the commit which was identified as causing the issue > occurred back in March, yet this thread was in June. So perhaps there > may be other commits interacting here (or that was the time when the > commit previously identified was merged into the next branch). Earlier this year, I was working on lots of performance metrics of CMake and this was part of it. There ended up being more than a dozen branches resulting from that work (some of them still unmerged). Doing some digging shows that this is where the commit finally hit master: commit bd20dd6b8a925a421167602027fff9b904fd0822 Merge: b041fc1 e17a69b Author: Brad King Date: Thu Jun 12 11:28:44 2014 -0400 so June looks right. --Ben -- 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
Re: [cmake-developers] [bcooks...@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]
On Fri, Oct 24, 2014 at 10:22:49 -0400, Ben Boeckel wrote: > > For preventing this in the future, would it be possible to set up > > Jenkins build to submit builds for kdelibs and a few other libraries > > which would test CMake master and submit to CMake's dashboard some > > results nightly so we can catch these problems more quickly? There are > > examples in: > > > > https://github.com/Kitware/CMake/tree/master/Tests/Contracts > > > > for how this is done for other projects already. The instance would > > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run > > CMake's test suite and submit to the dashboard. > > Theoretically that is possible, although a little complicated. We > would have to chain two or more Frameworks builds (each one relying on > the results of the prior build) in this case in order to detect the > regression which tripped us up here. It is something which would need > some adjustments to how our CI scripts work, but is certainly > feasible. > > Just to be sure, such a job would: > > 1) Build the latest CMake (branch next) > 2) Use the newly built CMake to compile all of the Frameworks, run > their unit tests and submit each one to CDash. > 3) Execute the CMake unit tests and submit this to CDash as well. > > For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS > variable apply? ie. they would all be kde-frameworks or similar, even > though we're making multiple submissions? So the way it works is that the contract build actually happens during CMake's ctest run. So to do this, you could add two libraries which depend on each other into the contract test. Basically all that needs to be done is to set up externalproject_add calls for the two with proper dependencies between them. There shouldn't be a need for building cmake then chaining it out to some other build instance. --Ben -- 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-developers] [bcooks...@kde.org: Re: [bcooks...@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]]
- Forwarded message from Ben Cooksley - Date: Sun, 26 Oct 2014 11:50:45 +1300 From: Ben Cooksley To: Ben Boeckel Subject: Re: [bcooks...@kde.org: Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch] On Sun, Oct 26, 2014 at 3:02 AM, Ben Boeckel wrote: > On Fri, Oct 24, 2014 at 10:22:49 -0400, Ben Boeckel wrote: >> > For preventing this in the future, would it be possible to set up >> > Jenkins build to submit builds for kdelibs and a few other libraries >> > which would test CMake master and submit to CMake's dashboard some >> > results nightly so we can catch these problems more quickly? There are >> > examples in: >> > >> > https://github.com/Kitware/CMake/tree/master/Tests/Contracts >> > >> > for how this is done for other projects already. The instance would >> > then just to set something like CMAKE_CONTRACT_PROJECTS=kdelibs and run >> > CMake's test suite and submit to the dashboard. >> >> Theoretically that is possible, although a little complicated. We >> would have to chain two or more Frameworks builds (each one relying on >> the results of the prior build) in this case in order to detect the >> regression which tripped us up here. It is something which would need >> some adjustments to how our CI scripts work, but is certainly >> feasible. >> >> Just to be sure, such a job would: >> >> 1) Build the latest CMake (branch next) >> 2) Use the newly built CMake to compile all of the Frameworks, run >> their unit tests and submit each one to CDash. >> 3) Execute the CMake unit tests and submit this to CDash as well. >> >> For each submission to CDash, would the same CMAKE_CONTRACT_PROJECTS >> variable apply? ie. they would all be kde-frameworks or similar, even >> though we're making multiple submissions? > > So the way it works is that the contract build actually happens during > CMake's ctest run. So to do this, you could add two libraries which > depend on each other into the contract test. Basically all that needs to > be done is to set up externalproject_add calls for the two with proper > dependencies between them. > > There shouldn't be a need for building cmake then chaining it out to > some other build instance. Okay, that sort of simplifies things a bit. I'll need to look into this further and probably talk with someone who is more familiar with CMake than I am to help to get it sorted out, but it should be possible to get this arranged with our setup. (The list still has me blocked, so this will need to be forwarded as well) > > --Ben Thanks, Ben - End forwarded message - -- 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
Re: [cmake-developers] cmake-gui icons
On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: > Trying to bring a bit more attention to this: > > Fedora is pushing to have higher resolution icons for the applications. There > already is CMakeSetup128.png, but these would need to get installed into the > proper /usr/share/icons/ hierarchy and named appropriately for the correct > size to be automatically found and used. It would be good to have cmake-gui be > conformant to the current desktop standards. > > Related - > > http://www.cmake.org/Bug/view.php?id=13504 > http://www.cmake.org/Bug/view.php?id=14315 > > Also might want to consider shipping AppData information. > > http://people.freedesktop.org/~hughsient/appdata/ I think there's a bug about this too (or at least for appdata). My question is: does it really make sense to have appdata for CMake's GUI? It isn't an "end user" application and I feel that developers "know" about CMake's Qt UI (or at least wouldn't look for it in the application tool thing). (I'm not against AppData overall; just wondering whether it makes sense for development tools such as cmake-gui.) Others' thoughts? --Ben -- 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
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Tue, Oct 28, 2014 at 09:58:58 +1300, Ben Cooksley wrote:
> If anyone is interested, help would be appreciated to get a Contracts
> style build up and running.
> In particular, pointers to documentation on how to perform such builds
> would be appreciated - we'll need to run "make install" for parts of
> it which doesn't seem to happen in any of the existing examples as far
> as I can see.
Since it's a CMake build, ExternalProject should make it fairly
straightforward. A quick sketch of the non-boilerplate code I see in the
current contracts tests:
externalproject_add(kdelibs
GIT_REPOSITORY [...]
GIT_TAG[...] # The oldest supported release.
CMAKE_ARGS
[...]
INSTALL_DIR"${CMAKE_CURRENT_BINARY_DIR}/install")
externalproject_add(someotherkdelib
DEPENDSkdelibs
GIT_REPOSITORY [...]
GIT_TAG[...] # The oldest supported release.
CMAKE_ARGS
# Might not be necessary.
"-DCMAKE_MODULE_PATH={$CMAKE_CURRENT_BINARY_DIR}/install/lib/cmake"
[...]
INSTALL_DIR"${CMAKE_CURRENT_BINARY_DIR}/install")
The rationale for using the oldest supported release is so that we make
sure whatever was written *then* still works today.
--Ben
--
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
Re: [cmake-developers] cmake-gui icons
On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: > Fedora is pushing to have higher resolution icons for the applications. There > already is CMakeSetup128.png, but these would need to get installed into the > proper /usr/share/icons/ hierarchy and named appropriately for the correct > size to be automatically found and used. It would be good to have cmake-gui be > conformant to the current desktop standards. The 128x128 is now installed with the branch currently on stage (and next): unix-icon-install This also stops installing the files on Apple where, at least AFAIK, the .desktop and other freedesktop.org files are never actually used. If these files are important on Apple, please chime in (MacPorts and/or homebrew? KDE or GNOME on OS X?). --Ben -- 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
Re: [cmake-developers] [wip/patch] Expose Ninja console pool feature for custom commands/targets
On Mon, Nov 03, 2014 at 16:22:56 -0800, Peter Collingbourne wrote:
> This patch exposes the Ninja console pool feature via the add_custom_command
> and add_custom_target commands. Specifically, it introduces a USE_CONSOLE
> flag which can be used to communicate to the generator that the command
> would prefer to use the console. It has no effect on generators other than
> the Ninja generator.
>
> The patch also causes the feature to be used with the built-in cache editor.
+1 to the feature. I think there are some bugs open on the tracker for
this we should ping when appropriate.
> Docs/tests to come. Any comments on the proposed approach are appreciated.
See inline below.
> -doing_verbatim
> +doing_nothing
A separate commit to rename this would be nice.
> +else if(copy == "USE_CONSOLE")
> + {
> + doing = doing_nothing;
> + console = true;
> + }
Is there any reason this could not be implemented with a JOB_POOL target
property? This would allow custom commands to be placed into a pool with
JOB_POOLS other than the console pool.
>cmTarget CreateGlobalTarget(const std::string& name, const char* message,
> const cmCustomCommandLines* commandLines,
> -std::vector depends, const char* workingDir);
> +std::vector depends, const char* workingDir,
> +bool console);
A separate commit to add this parameter would be nice so that the "make
current things console'd" is separate from "allow the user to make
targets console'd". This parameter might not even be necessary with a
generic JOB_POOL target property.
Thanks,
--Ben
--
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
