Re: [cmake-developers] zsh user out there ?

2010-06-22 Thread Ben Boeckel
Sorry for the self-reply, but I thought these might also be useful: -- ZSH --- # Directory changing stuff alias cb=cd src build alias cs=cd build src alias cdp=cd \$PWD alias dcl=dirs -c mcwd () { cb || exit 1 make $@ popd } -- VIM ---

[cmake-developers] FindPythonLibs fixes for Python3

2012-03-28 Thread Ben Boeckel
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 maths...@gmail.com Date: Tue

Re: [cmake-developers] ninja command line options ?

2012-04-03 Thread Ben Boeckel
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

Re: [cmake-developers] FindCXX11.cmake

2012-04-09 Thread Ben Boeckel
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(

Re: [cmake-developers] Target usage requirements and conventions

2012-05-03 Thread Ben Boeckel
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

Re: [cmake-developers] Using tags in Mantis

2013-11-21 Thread Ben Boeckel
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

Re: [cmake-developers] Review Request: Topic ExternalProject_GitUpdate

2013-12-03 Thread Ben Boeckel
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

Re: [cmake-developers] Review Request: Topic ExternalProject_GitUpdate

2013-12-03 Thread Ben Boeckel
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Ben Boeckel
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Ben Boeckel
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Ben Boeckel
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*

Re: [cmake-developers] Generators and Extra Generators

2014-01-07 Thread Ben Boeckel
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

Re: [cmake-developers] Generators and Extra Generators

2014-01-07 Thread Ben Boeckel
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

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

2014-01-16 Thread Ben Boeckel
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 $$NOT: $CONFIG:Debug:QT_NO_DEBUG)

Re: [cmake-developers] CMAKE_CONFIGURATION_TYPES

2014-02-05 Thread Ben Boeckel
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

Re: [cmake-developers] add_custom_command differences in tests

2014-02-06 Thread Ben Boeckel
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.

Re: [cmake-developers] [PSA] API changes to use strings

2014-02-06 Thread Ben Boeckel
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

Re: [cmake-developers] Preparing for CMake 3.0-rc1

2014-02-07 Thread Ben Boeckel
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

[cmake-developers] Branches on next

2014-02-11 Thread Ben Boeckel
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

Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)

2014-02-11 Thread Ben Boeckel
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

Re: [cmake-developers] dev/custom-parsers topic (was: Branches on next)

2014-02-11 Thread Ben Boeckel
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

Re: [cmake-developers] Branches on next

2014-02-11 Thread Ben Boeckel
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.

Re: [cmake-developers] Branches on next

2014-02-11 Thread Ben Boeckel
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

Re: [cmake-developers] Branches on next

2014-02-12 Thread Ben Boeckel
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

Re: [cmake-developers] Branches on next

2014-02-12 Thread Ben Boeckel
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

Re: [cmake-developers] Branches on next

2014-02-12 Thread Ben Boeckel
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

Re: [cmake-developers] Branches on next

2014-02-12 Thread Ben Boeckel
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

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Ben Boeckel
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

Re: [cmake-developers] Objective-C support

2014-02-14 Thread Ben Boeckel
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.

Re: [cmake-developers] GIT push access please

2014-02-16 Thread Ben Boeckel
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

[cmake-developers] New EVIS parser moving forward (3.1)

2014-02-18 Thread Ben Boeckel
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

Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-18 Thread Ben Boeckel
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,

Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-21 Thread Ben Boeckel
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

Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-21 Thread Ben Boeckel
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

Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-21 Thread Ben Boeckel
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:

Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-21 Thread Ben Boeckel
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

Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-21 Thread Ben Boeckel
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

Re: [cmake-developers] Recommendations for reducing spurious link dependencies?

2014-02-21 Thread Ben Boeckel
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.

Re: [cmake-developers] Recommendations for reducing spurious link dependencies?

2014-02-22 Thread Ben Boeckel
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

[cmake-developers] Custom Ninja deptypes

2014-03-24 Thread Ben Boeckel
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_LANG. It is done after the custom MSVC check since it requires other logic besides just changing the 'deps' Ninja rule variable.

[cmake-developers] FindFoo.cmake and COMPONENTS

2014-03-26 Thread Ben Boeckel
[ 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

Re: [cmake-developers] FindFoo.cmake and COMPONENTS

2014-03-26 Thread Ben Boeckel
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

Re: [cmake-developers] [PATCH] A little simplify Ninja code for linker commands

2014-03-31 Thread Ben Boeckel
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

Re: [cmake-developers] CMake master slowdown in generation step

2014-04-04 Thread Ben Boeckel
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

Re: [cmake-developers] CMake master slowdown in generation step

2014-04-04 Thread Ben Boeckel
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

Re: [cmake-developers] CMake master slowdown in generation step

2014-04-10 Thread Ben Boeckel
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

Re: [cmake-developers] [PATCH] remove x placeholder from STREQUAL operands

2014-04-17 Thread Ben Boeckel
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.)

Re: [cmake-developers] [PATCH] remove x placeholder from STREQUAL operands

2014-04-18 Thread Ben Boeckel
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

Re: [cmake-developers] generator expressions with variable

2014-04-19 Thread Ben Boeckel
On Sat, Apr 19, 2014 at 12:08:42 +0200, Tim Blechmann wrote: $$BOOL:$TARGET_PROPERTY:${TARGET},INCLUDE_DIRECTORIES:-I$JOIN:$TARGET_PROPERTY:${TARGET},INCLUDE_DIRECTORIES, -I Does it work without the variable in there. (By the time the generator expression evaluator gets the string, it should

Re: [cmake-developers] CMP0043 warnings everywhere

2014-04-29 Thread Ben Boeckel
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

Re: [cmake-developers] CMP0043 warnings everywhere

2014-04-29 Thread Ben Boeckel
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

Re: [cmake-developers] Weird dependency on object files generated elsewhere

2014-05-08 Thread Ben Boeckel
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

Re: [cmake-developers] What about #line like feature in cmake language?

2014-05-15 Thread Ben Boeckel
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

Re: [cmake-developers] What about #line like feature in cmake language?

2014-05-15 Thread Ben Boeckel
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

Re: [cmake-developers] Any plans to remove the limitation in command line length for the cmake -E remove command?

2014-05-15 Thread Ben Boeckel
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

Re: [cmake-developers] Any plans to remove the limitation in command line length for the cmake -E remove command?

2014-05-16 Thread Ben Boeckel
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

Re: [cmake-developers] New no-soname-option topic for e.g. Android

2014-05-28 Thread Ben Boeckel
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

Re: [cmake-developers] New no-soname-option topic for e.g. Android

2014-05-28 Thread Ben Boeckel
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

Re: [cmake-developers] Compiler features/extensions remaining/future issues

2014-06-08 Thread Ben Boeckel
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. snip 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,

Re: [cmake-developers] Compiler features/extensions remaining/future issues

2014-06-09 Thread Ben Boeckel
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

[cmake-developers] add_compile_options and link flags

2014-06-09 Thread Ben Boeckel
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,

Re: [cmake-developers] Compiler features/extensions remaining/future issues

2014-06-10 Thread Ben Boeckel
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

Re: [cmake-developers] Compiler features/extensions remaining/future issues

2014-06-10 Thread Ben Boeckel
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

Re: [cmake-developers] cost of usage requirements (was: Compiler features/extensions remaining/future issues)

2014-06-11 Thread Ben Boeckel
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

Re: [cmake-developers] Clang 3.5-svn emmits tautological-pointer-compare warning

2014-06-21 Thread Ben Boeckel
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

Re: [cmake-developers] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)

2014-06-24 Thread Ben Boeckel
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.

Re: [cmake-developers] Weird build error against libc++ on OS X 10.7 (cutting at 1024 characters)

2014-06-24 Thread Ben Boeckel
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

Re: [cmake-developers] IMPORTED targets for some Find modules

2014-06-25 Thread Ben Boeckel
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

Re: [cmake-developers] [RFC] ctest: do not output failed when no tests failed

2014-06-26 Thread Ben Boeckel
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:

Re: [cmake-developers] [patch] install cfbundles as directory

2014-07-09 Thread Ben Boeckel
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

Re: [cmake-developers] [patch] fix Info.plist parser

2014-08-11 Thread Ben Boeckel
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

Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

2014-10-03 Thread Ben Boeckel
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

Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

2014-10-06 Thread Ben Boeckel
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

Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

2014-10-06 Thread Ben Boeckel
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

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

2014-10-13 Thread Ben Boeckel
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

Re: [cmake-developers] [PATCH] Ninja: Use 'console' pool for CMake re-run if possible

2014-10-14 Thread Ben Boeckel
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

Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions in release branch

2014-10-23 Thread Ben Boeckel
[ 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

[cmake-developers] [bcooks...@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]

2014-10-24 Thread Ben Boeckel
@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 ben.boec...@kitware.com wrote: [ Adding Ben Cooksley to the CC list; feel free to reply privately and I'll forward to the list if you

Re: [cmake-developers] Severe behavioural change regressions in release branch

2014-10-24 Thread Ben Boeckel
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 ben.boec...@kitware.com Date: Wed Mar 12 14:01:45 2014 -0400

Re: [cmake-developers] Severe behavioural change regressions in release branch

2014-10-24 Thread Ben Boeckel
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

Re: [cmake-developers] Severe behavioural change regressions in release branch

2014-10-24 Thread Ben Boeckel
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

Re: [cmake-developers] Severe behavioural change regressions in release branch

2014-10-24 Thread Ben Boeckel
On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com 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

Re: [cmake-developers] [bcooks...@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]

2014-10-25 Thread Ben Boeckel
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

[cmake-developers] [bcooks...@kde.org: Re: [bcooks...@kde.org: Re: Fwd: Re: Severe behavioural change regressions in release branch]]

2014-10-27 Thread Ben Boeckel
- Forwarded message from Ben Cooksley bcooks...@kde.org - Date: Sun, 26 Oct 2014 11:50:45 +1300 From: Ben Cooksley bcooks...@kde.org To: Ben Boeckel ben.boec...@kitware.com Subject: Re: [bcooks...@kde.org: Re: [cmake-developers] Fwd: Re: Severe behavioural change regressions

Re: [cmake-developers] cmake-gui icons

2014-10-27 Thread Ben Boeckel
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/

Re: [cmake-developers] Severe behavioural change regressions in release branch

2014-10-27 Thread Ben Boeckel
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

Re: [cmake-developers] cmake-gui icons

2014-10-29 Thread Ben Boeckel
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

Re: [cmake-developers] [wip/patch] Expose Ninja console pool feature for custom commands/targets

2014-11-03 Thread Ben Boeckel
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

Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Ben Boeckel
On Fri, Nov 07, 2014 at 09:51:39 -0500, Brad King wrote: On Thu, Nov 6, 2014 at 11:09 PM, Clinton Stimpson wrote: isn't the GetOrCreateSourceFile call superfluous if you have a pointer to the source file object in the iterator...? IIUC that is to create a cmSourceFile entry for the object

Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Ben Boeckel
On Fri, Nov 07, 2014 at 11:52:45 -0500, Brad King wrote: OTOH, it is possible that application code tries to set a property on an object file ahead of time. AFAIK, CMake doesn't expose where it stores these files and has always treated it as an internal detail. Is this something we promise

Re: [cmake-developers] [PATCH v5 0/4] Add continue keyword

2014-11-18 Thread Ben Boeckel
On Tue, Nov 18, 2014 at 16:34:28 +0100, Gregor Jasny wrote: Changes compared to v4: * Use new style error reporting in cmContinueCommand.cxx * Reject any given arguments to continue() * CMP0055: Reject any arguments to break, too. Untested, but from a (very) quick skim, I don't see anything

Re: [cmake-developers] [PATCH v5 0/4] Add continue keyword

2014-11-18 Thread Ben Boeckel
On Tue, Nov 18, 2014 at 18:06:30 +0100, Gregor Jasny wrote: On 18/11/14 17:19, Ben Boeckel wrote: I wonder if we should fix anything about it and if so, make continue behave in an analogous way You want to make continue() bug compatible to break()? There are two parts here: 1

Re: [cmake-developers] Patch for new warning caused by CMP0054

2014-11-19 Thread Ben Boeckel
On Tue, Nov 18, 2014 at 23:18:20 +, Fraser Hutchison wrote: -if(CMAKE_C_SIMULATE_ID STREQUAL MSVC - OR CMAKE_CXX_SIMULATE_ID STREQUAL MSVC - OR CMAKE_Fortran_SIMULATE_ID STREQUAL MSVC - OR CMAKE_C_COMPILER_ID STREQUAL MSVC - OR CMAKE_CXX_COMPILER_ID STREQUAL MSVC

Re: [cmake-developers] Patch for new warning caused by CMP0054

2014-11-19 Thread Ben Boeckel
On Wed, Nov 19, 2014 at 11:05:48 -0500, Ben Boeckel wrote: snip And I now see Rolf's reply. Should have waited for email to refresh. --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

Re: [cmake-developers] Patch for new warning caused by CMP0054

2014-11-19 Thread Ben Boeckel
On Wed, Nov 19, 2014 at 21:02:35 +, Fraser Hutchison wrote: Yeah - no worries. I understand my previous mistake and what's in the patch should now be OK I think. However, I'm more than happy if you want to fix this another way and reject the patch - but it'd be good to nail this

[cmake-developers] New RelWithDebInfo flags?

2014-11-22 Thread Ben Boeckel
Hi, I just discovered today that it looks like GCC 4.8 shipped with a new optimization level: -Og Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug

Re: [cmake-developers] New RelWithDebInfo flags?

2014-11-22 Thread Ben Boeckel
On Sat, Nov 22, 2014 at 10:12:22 -0700, clin...@elemtech.com wrote: Perhaps not if people are using that configuration to build release binaries and stripping debug symbols from it. Ah, true. Maybe it would be better for Debug than RelWithDebInfo? In my opinion, it *does* interfere with

[cmake-developers] OpenBSD and srand()/rand() changes

2014-12-10 Thread Ben Boeckel
Hi, It appears[1] as though OpenBSD has changed srand and rand which we use in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a no-op there. Do we want to use rand_deterministic and srand_determinitic or does it not matter? --Ben

Re: [cmake-developers] OpenBSD and srand()/rand() changes

2014-12-13 Thread Ben Boeckel
On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote: Yes, setting an explicit seed should make subsequent calls to random be deterministic... Well, *we* want that, but I don't think that OpenBSD is making an *awful* decision here. Even if you want deterministic,

Re: [cmake-developers] Improving Vim support in CMake

2015-01-26 Thread Ben Boeckel
On Sat, Jan 24, 2015 at 15:29:51 +, Alex Merry wrote: On Wednesday 21 January 2015 16:17:35 Ben Boeckel wrote: List of improvements to the syntax file: - drop support for 7.0 (which is 7.5 years old now); - add support for Lua-style comments; - update the list of system

  1   2   3   >