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 ---
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
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
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(
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
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
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
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
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
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
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*
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
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
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)
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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
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
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,
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
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
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:
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
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
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.
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
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.
[ 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
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
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
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
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
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
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.)
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
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
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
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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
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.
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
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
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:
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
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
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
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
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
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
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
[ 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.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
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
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
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
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
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
- 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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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 - 100 of 293 matches
Mail list logo
