On 2015-01-09 14:18, Rolf Eike Beer wrote:
Matthew Woehlke wrote:
On 2014-10-03 03:35, Rolf Eike Beer wrote:
find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed.. In
most cases this behavior is not the one that one would expect or need.
Most people would instead allow any 2.0.x
On 2014-10-03 03:35, Rolf Eike Beer wrote:
find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most
cases this behavior is not the one that one would expect or need. Most people
would instead allow any 2.0.x version to match. This sort of selection is
currently impossible
On 2014-12-22 19:30, Aleix Pol wrote:
On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev wrote:
* No progress indication. Since the generation may take several minutes,
providing feedback is crucial.
I never found such case,
ParaView. (To a lesser extent, VTK.)
I would argue that a project
On 2014-10-13 10:39, Brad King wrote:
On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
Locking directory is equivalent to locking file `cmake.lock` in
directory /path/to/shared/directory/:
I think this can be activated buy a DIRECTORY option.
Why do we need even that? Can't CMake just test if
On 2014-07-25 17:05, Williams, Norman K wrote:
There’s also the ‘console pool’ facility that would allow
ExternalProject builds to display output, though that would get back
to the Gmake issue of different processes interleaving output.
It wouldn't; the 'console' pool only permits one job at a
On 2014-10-03 08:56, Brad King wrote:
On 10/02/2014 06:08 PM, Matthew Woehlke wrote:
Please see also
http://public.kitware.com/Bug/view.php?id=14915 which it sounds like
this (partly) fixes; you may want to reference that in your patch or
vice versa.
I've applied the patch here and added
On 2014-10-03 14:00, Sylvain Joubert wrote:
Le 03/10/2014 17:41, Matthew Woehlke a écrit :
On 2014-10-03 08:56, Brad King wrote:
I'll leave that to a follow-up patch if anyone wants to do it.
I was sort-of hoping / encouraging that Sylvain might be interested :-).
I quickly checked
On 2014-10-02 17:34, Sylvain Joubert wrote:
Since Ninja 1.5, a pre-defined pool 'console' can be used for non
buffered output.
See
http://martine.github.io/ninja/manual.html#_the_literal_console_literal_pool
This patch specifies that special pool for the build.ninja build block
if the
On 2014-05-29 08:56, Brad King wrote:
I did not realize in my previous response that you intend
to execute a cp process, but rather thought you would
be implementing the underlying calls to the filesystem
directly.
That was my assumption also. I would've thought that would be better, as
On 2014-05-15 08:36, Ben Boeckel wrote:
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
On 2014-05-21 15:24, Nicolas Desprès wrote:
On Wed, May 21, 2014 at 8:06 PM, Matthew Woehlke wrote:
On 2014-05-15 08:36, Ben Boeckel wrote:
This will also likely need a policy since there's no guarantee that
#line directives don't exist in already existing code as comments.
Maybe we should
On 2014-04-24 08:35, Nils Gladitz wrote:
On 04/24/2014 02:17 PM, Alan W. Irwin wrote:
I also just discovered that --help-man and --help-html were gone as
well for those who preferred man or html formatting of the full
documentation as opposed to the ascii form delivered by --help-full.
The
On 2014-04-24 14:42, Alan W. Irwin wrote:
So my remaining question (without all the html and man distractions)
boils down to a request to implement --help-full as the concatanation
(following the same order as the present CMake 2 results) of those
individual manual results.
Come to think of
On 2014-04-18 09:07, Brad King wrote:
On 04/18/2014 08:58 AM, Rolf Eike Beer wrote:
To forbid whitespace and control characters in variable names can IMHO only be
good.
Some people use arbitrary variable names as a way to do key/value tables.
In such cases it is intentional to use arbitrary
On 2014-04-23 16:21, Alan W. Irwin wrote:
[...] I keep making a plea for a proper fix to bug 9220 because
propagating compiler information (held potentially in a large number
of different environment variables and CMake variables for many
different computer languages) from the principal CMake
On 2014-04-17 07:56, Peter Kümmel wrote:
Is there a way to configure the default generator for command-line cmake
calls?
If you're using bash: 'alias cmake=cmake -GNinja' (for example)...
I'm not sure how folks would feel about having a different default built
into the cmake binary itself
On 2014-02-21 16:34, Ben Boeckel wrote:
Other than varname, 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 varname that we *only* support implicit
dereference, but it may be too hard to detect:
On 2014-02-11 23:03, Ben Boeckel wrote:
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
On 2014-02-11 23:03, Ben Boeckel wrote:
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
On 2014-02-11 17:54, Ben Boeckel wrote:
ExpandVariablesInString is the part which takes a string which may have
variables in it and dereferences them.
Yes, that's why your changes
On 2014-02-08 06:10, Stephen Kelly wrote:
3) Assuming you still have no local changes,
git reset --hard origin/LinkOptionsCommand
Worth adding: If you *do* have local changes, you can (before running
the above) set them aside with git stash and (after running the above)
restore them with
On 2014-02-07 13:57, Brad King wrote:
There is one more change I'd like to make as part of the change
to the 3.0 version number. I propose that we drop the fourth
version component and use only two components for the feature
level.
I guess this will mean that minor release are much more
On 2014-02-03 14:44, Stephen Kelly wrote:
Additionally, sphinx is not the only tool processing the rst. The kate
editor also does syntax highlighting of the blocks. It should (but currently
does not) highlight the 'invalid' cmake code as invalid.
I guess you mean that in a '..code-block::
On 2014-01-29 09:58, Brad King wrote:
I reverted the 'AddVersionToProjectCommand' topic from 'next'
and replaced it with a 'project-version-variables' topic that
adds a policy:
Help: Format project command and variable documentation
On 2014-01-28 11:16, Jean-Christophe Fillion-Robin wrote:
On Tue, Jan 28, 2014 at 9:10 AM, Brad King wrote:
So our options are
(1) Design new behavior in a way that requires a change to the
project to activate.
(2) Add a policy. The policy should only trigger when the
project()
On 2014-01-27 16:58, Stephen Kelly wrote:
Though I still don't like the behavior in the topic with project() commands
without a specified VERSION and the
CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see why
all the complexity is needed.
From what I understand, the reason
On 2014-01-15 16:25, Alexander Neundorf wrote:
On Wednesday 15 January 2014, Alexander Neundorf wrote:
And, to actually produce the breakage, at some place the VERSION argument
must have been added.
With the current state of my branch, this could be worked around by
unsetting the guard
On 2014-01-14 10:37, Brad King wrote:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for
On 2014-01-14 14:11, Daniel Pfeifer wrote:
2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net:
@Daniel, there is a CMAKE_PROJECT_NAME?
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME
On 2014-01-14 18:00, Alexander Neundorf wrote:
On Tuesday 14 January 2014, Matthew Woehlke wrote:
While that sounds good for 99.9% of cases, what about the case of
project A that includes project B, where B is not updated, but A decides
to start using project(...VERSION...). Now if B was using
On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:
Would it make sense to have project(Foo VERSION 1.2.3) set the variables:
${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
That way, the variable would remain even if project is called with VERSION
in sub directory.
How is
On 2014-01-10 15:15, Alexander Neundorf wrote:
On Friday 10 January 2014, Matthew Woehlke wrote:
Related: Do these affect the version properties of libraries? (Because
OTOH if it does, I can imagine wanting to say VERSION once at the root
and have it inherit downwards unless overridden. Maybe
On 2014-01-08 11:26, Brad King wrote:
On 11/20/2013 07:22 PM, Stephen Kelly wrote:
The solution is still to re-implement the --help-custom-modules myman.1
command-line behavior as a special case with warnings. Alex and Steve
will have to work out who takes responsibility for that.
In order
On 2014-01-08 12:57, Brad King wrote:
On 01/08/2014 12:00 PM, Matthew Woehlke wrote:
Since you mentioned it, I was wondering if this is related to a feature
I was asking about, but I don't understand how it works; it seems to
only ever generate a short boilerplate text.
Is this meant to take
On 2013-12-19 11:21, Brad King wrote:
On 12/18/2013 12:13 PM, Matthew Woehlke wrote:
Does this mean one cannot e.g. use the CMake extensions and/or link to
topics in CMake's documentation (provided a known location of the same)?
Correct. Sphinx does not support magic cross-referencing
On 2014-01-08 15:35, Brad King wrote:
On 01/08/2014 01:52 PM, Matthew Woehlke wrote:
On 2013-12-19 11:21, Brad King wrote:
Sphinx does not support magic cross-referencing to external documents.
If that's really true, that's a pretty big drawback of docutils vs. e.g.
doxygen, which has very
On 2013-12-18 11:52, Brad King wrote:
On 12/12/2013 01:19 PM, Matthew Woehlke wrote:
Loosely related: is there a way to make export() and install(EXPORT) set
these properties for exported targets?
Not of which I'm aware. You can have your package configuration file
add them after loading
On 2013-12-18 11:52, Brad King wrote:
On 12/10/2013 04:46 PM, Matthew Woehlke wrote:
Why is the copyright notice *after* the documentation?
In the old documentation system the extractor only supported
docs in the leading comment so the notice *had* to be later.
Now it is just a convention
On 2013-12-18 11:52, Brad King wrote:
On 12/10/2013 04:57 PM, Matthew Woehlke wrote:
Thanks. Are there any guidelines on documenting the parameters of CMake
functions/macros? I didn't see that in the mentioned document.
No convention has been established so there is none to document yet.
We
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a lower
level library causes more than a hundred targets to be relinked, for no
good
On 2013-12-11 17:40, Bill Hoffman wrote:
On 12/11/2013 5:13 PM, Matthew Woehlke wrote:
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change
On 2013-12-11 17:13, Matthew Woehlke wrote:
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a lower
level library causes more than a hundred
On 2013-12-11 19:21, Ben Boeckel wrote:
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
On 2013-11-22 15:49, Brad King wrote:
On 11/22/2013 03:24 PM, Matthew Woehlke wrote:
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation immediately preceding the function definitions
On 2013-11-22 15:49, Brad King wrote:
On 11/22/2013 03:24 PM, Matthew Woehlke wrote:
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation immediately preceding the function definitions
On 2013-12-06 14:51, Daniele E. Domenichelli wrote:
Are you sure you don't want the command to be renamed to
parse_arguments? The only commands containing cmake looks strictly
related to cmake, and the arguments parsing does not look that much
related...
FWIW, I was sort-of hoping it would be.
On 2013-12-05 02:36, Alan W. Irwin wrote:
Sorry, this turned out to be a false alarm. Despite which cmake
telling me I was using cmake-2.8.12.1 [snip]
...which is, of course, why you should always use type in bash rather
than which :-). type, being a shell built-in, will tell you what
bash
Now that CMake is using RST for documentations, is there a good guide
for how to document modules that mainly provide new functions?
In particular, I am wondering if it is possible, and if so, what
recommendations there are if any, to document functions 'doxygen style',
i.e. the documentation
On 2013-11-15 04:05, Nils Gladitz wrote:
I would like to hijack/extend Stephen's changes in
05f5fde0eb83c0e49aab3214f28a098861aa3313
to also disallow target names that have been implicitly reserved by some
of the generators.
This list might not be complete but I assume it would be at least:
On 2013-11-11 03:15, Nils Gladitz wrote:
Could output of the ninja progress indicator be omitted for when it
reruns cmake somehow?
It outputs 1/1 and then goes on to report the actual progress e.g.
1/916 ...
What else can you do? Until you re-run CMake, there is no way to know
how many edges
On 2013-11-06 13:57, Brad King wrote:
On 11/06/2013 01:32 PM, Alexander Neundorf wrote:
Adding proper named argument handling to cmake_parse_arguments() itself is
somewhat complicated since it can't make use of cmake_parse_arguments() ;-)
Since the need for this is so common, perhaps we
On 2013-11-05 14:36, Alexander Neundorf wrote:
I tried the following a few times in the past and noticed everytime that it
does not work:
$ cd src
src/ $ mkdir build
src/ $ cd build
src/build/ $ cmake-gui -DSOME_VARIABLE=some_value ..
I'd like that to work. Would it work with your proposal ?
On 2013-11-05 14:36, Alexander Neundorf wrote:
On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote:
Would it makes sense to have cmake-gui behaving like ccmake ? After all
there are both UI.
It would accept the same set of options:
[...]
-G generator-name = Specify a
On 2013-11-05 15:14, physhh . wrote:
On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote:
On 2013-11-05 14:36, Alexander Neundorf wrote:
Once the cache is deleted in cmake-gui, I would expect that the
values from the command line are also forgotten, also the -U
values. Otherwise this cmake
On 2013-11-04 15:47, David Cole wrote:
My question is still not answered completely:
When should the new variable be added? On startup is not really
possible because it might be the case that your src/binary directory
is not set properly.
So you would agree that it makes sense to do it on
On 2013-10-17 16:59, Brad King wrote:
On 10/17/2013 04:56 PM, Rolf Eike Beer wrote:
We should think if this should be something that is needed. Running some sort
of background process is a common pattern for all sorts of tests. Often really
detaching is not needed, It is usually sufficient to
On 2013-10-15 18:44, Pedro Navarro wrote:
I'm imagining that, depending on the testing machine, we might need to be
able to specify where the perforce server is located, if it's not the local
machine (using either a command line switch or an environment variable). Is
there any infrastructure for
On 2013-08-31 20:42, outro pessoa wrote:
It's that simple.
1. I know that this isn't the traverso mailing list.
2. There is no response; and, therefore, it is up to me to fix it.
3. Resetting vorbis/vorbisfile.h to accept the FreeBSD paths does not work.
4. Contacting the former maintainers
On 2013-09-02 11:15, Matthew Woehlke wrote:
On 2013-08-31 20:42, outro pessoa wrote:
It's that simple.
1. I know that this isn't the traverso mailing list.
2. There is no response; and, therefore, it is up to me to fix it.
3. Resetting vorbis/vorbisfile.h to accept the FreeBSD paths does
On 2013-07-30 08:45, Brad King wrote:
On 07/30/2013 06:30 AM, Stephen Kelly wrote:
I wonder if we should add --deprecated-warnings and --deprecated-errors and
document them in cmake --help, as --warn-uninitialized etc? I think it's
something we can do after 2.8.12, but I want to make sure it
On 2013-07-25 11:25, Stephen Kelly wrote:
Brad King wrote:
On 07/25/2013 09:16 AM, Stephen Kelly wrote:
Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets
as SYSTEM includes automatically?
I don't think so because one could be importing targets from a dependency
that
On 2013-07-25 13:25, Stephen Kelly wrote:
Brad King wrote:
On 07/25/2013 12:22 PM, Stephen Kelly wrote:
library A should have a unit test which attempts to compile all
of its headers with all warnings enabled. In Qt every module has a
'headersclean' unit test which does exactly that.
While
On 2013-07-19 10:36, Nicolas Desprès wrote:
In Unix shell we can do that:
$ VAR=foo cmd in out
This way the environment variable is only set in the environment of the
process of the command and not the in current shell like when using the
export built-in.
I would like to be able to do the same
On 2013-06-28 08:40, Brad King wrote:
What about the APPEND mode of export? Do you plan to try to
collect all the appended pieces together, all delayed until
generate time?
That would be great if you could! One of my big gripes with export() is
how much less elegant it is generating a
On 2013-06-28 09:06, Stephen Kelly wrote:
Brad King wrote:
Perhaps the policy could also disallow the
APPEND mode altogether. IIRC I've participated in discussion
in the past about how APPEND is a bad approach anyway.
I've never used it, but then I've never used export() except in unit tests
On 2013-06-17 12:25, Matthew Woehlke wrote:
On 2013-06-17 09:59, paul.chav...@fnac.net wrote:
Following this thread¹ and bug², i would like to submit a patch that
allow to specify a Manifest.txt when creating a jar.
¹ http://www.cmake.org/pipermail/cmake/2011-December/048015.html
² http
On 2013-06-10 15:49, Alexander Neundorf wrote:
On Monday, June 10, 2013 09:19:15 AM Andreas Schneider wrote:
Hi,
I'm currently working on some libraries [1] which allows you advanced
testing of daemons. Especially ones which require a network in testing.
However for using this I need some
On 2013-05-30 08:47, Wojciech Knapik wrote:
Working with make taught me once and for all, that functions like
[execute_process] should be avoided whenever possible. A build tool
creates files from files via the means of targets. So if you want to
use a tool like this effectively, you should use
On 2013-05-28 19:50, Wojciech Knapik wrote:
Files don't just happen to be lying around in directories. You have to
create them in a specific path, with a specific name. Even if the act of
creation was performed by another developer, on another machine, that
information is written to disk in the
On 2013-05-28 21:23, Wojciech Knapik wrote:
On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote:
GLOB is just one of many things that will surprise you when working with
CMake if you don't understand the difference between the configure and
build passes.
I've written quite a bit
On 2013-05-21 15:54, Brad King wrote:
On 05/08/2013 05:09 PM, Matthew Woehlke wrote:
After chatting with Marcus how to resolve ParaView link errors due to
things using Google Protobuf needing to link to pthread, I have updated
FindProtobuf.cmake to also find the pthread library on UNIX
On 2013-05-24 15:56, Robert Maynard wrote:
Did you verify that you have ssh access to g...@cmake.org?
It was getting as far as dumping usage for 'stage' (elided in the
previous message), so yes.
Thanks to Brad King's help, it was determined to be a problem with my
access credentials that
After chatting with Marcus how to resolve ParaView link errors due to
things using Google Protobuf needing to link to pthread, I have updated
FindProtobuf.cmake to also find the pthread library on UNIX platforms
and include it in PROTOBUF_LIBRARIES.
This should fix link errors in a number of
On 2013-04-02 09:19, Brad King wrote:
Hi Peter,
We've come across a case where the Makefile, VS, and Xcode generators
work but Ninja does not::
cmake_minimum_required(VERSION 2.8.10)
project(DependSideEffect C)
add_library(A a.c)
add_custom_command(
TARGET A POST_BUILD
COMMAND
On 2013-03-26 08:16, Brad King wrote:
On 03/25/2013 05:20 PM, Matthew Woehlke wrote:
Actually, there is a fourth option: I could write a patch that ONLY adds
INCLUDE_JARS and doesn't touch the rest of the logic. This might be a
more reasonable avenue for adding jar dependency support without
On 2013-03-26 13:05, Rolf Eike Beer wrote:
Brad King wrote:
@@ -190,6 +198,8 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
+include(CMakeParseArguments)
+
function (__java_copy_file src dest comment)
I have pushed a branch (use-java-use-parse-arguments) to stage that
converts add_jar to using cmake_parse_arguments. This partly revers the
previous change to accept jars and jar targets as sources for 'linking';
these must now be explicitly specified with INCLUDE_JARS. Other named
arguments
On 2013-03-25 13:14, Brad King wrote:
On 03/25/2013 12:28 PM, Matthew Woehlke wrote:
I'm on the fence if this should target 2.8.11. On the plus side, it
means the historic behavior of ignoring jar files listed as sources will
be preserved. On the down side, it is late in the cycle
On 2013-03-25 14:07, Brad King wrote:
On 03/25/2013 01:46 PM, Matthew Woehlke wrote:
As is:
- Pros: add_jar accepts jars as it was apparently intended to, as
'source' arguments
- Cons: maybe not optimal interface, must support this going forward
Even after the proposed interface goes in we
On 2013-03-21 14:56, David Cole wrote:
Unfortunately, this entire discussion nicely demonstrates and reinforces
my belief that we ought not to do this == thing...
If Alex, Brad, Matthew and I can't understand each other's meanings
within the context of this discussion, what chance does a poor
On 2013-03-21 16:55, David Cole wrote:
I almost always do one of these for string compare to a CMake variable
value:
if(${var} STREQUAL some string constant)
if(${var} STREQUAL ${some_other_variable})
However, this is only because I am almost always certain that ${var}
does not
On 2013-03-20 17:10, David Cole wrote:
Are you proposing that == behaves as STREQUAL, or as EQUAL?
What's the difference?
Okay, for , , there is an obvious answer, but for ==, I am trying and
failing to think of a situation where treating the arguments as numbers
would give a different
On 2013-03-15 11:57, Robert Maynard wrote:
I am happy to announce that CMake 2.8.11 has entered the release candidate
stage.
I guess this does not include yesterday's genex fix? Will there be an
rc2 to pick that up?
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source
On 2013-03-14 11:14, Andreas Schneider wrote:
On Thursday 14 March 2013 10:57:10 Brad King wrote:
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
This is now pushed to stage/fix-java-jar-depends. If someone
knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas
If I have a target 'foo' and I do:
target_include_directories(foo INTERFACE
$BUILD_INTERFACE:hello
$INSTALL_INTERFACE:world
)
...then in the build export file, I see the interface include
directories 'hello', which seems reasonable.
However, if I do:
target_include_directories(foo
On 2013-03-14 16:46, Stephen Kelly wrote:
Matthew Woehlke wrote:
...then I get 'hello;$INSTALL_INTERFACE:world;left'.
Is this expected/correct?
Nope, this is a bug.
Thanks for testing/reporting. I've pushed a fix to the next branch. Please
try that out.
That seems to do the trick (no more
If I turn off BUILD_TESTING, I get this error:
CMake Error at Tests/CMakeTests/CMakeLists.txt:7 (add_test):
Error evaluating generator expression:
$TARGET_FILE:cmsysTestsCxx
No target cmsysTestsCxx
Call Stack (most recent call first):
Tests/CMakeTests/CMakeLists.txt:32
I've discovered an odd an seemingly incorrect behavior of
get_filename_component(REALPATH)... apparently there are some conditions
when it can take a canonical path and turn it *back into a symlink*.
To reproduce:
$ ls -l
lrwxrwxrwx. 1 matthew matthew 10 Mar 13 20:17 build - real-build
This simple CMakeLists.txt is broken with ninja:
cmake_minimum_required(VERSION 2.8.10.20130312)
project(Foo)
add_executable(foo foo.cpp)
target_include_directories(foo PUBLIC
$BUILD_INTERFACE:${Foo_BINARY_DIR}
$INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include
)
...with Ninja, the
On 2013-03-13 20:59, Matthew Woehlke wrote:
This simple CMakeLists.txt is broken with ninja:
cmake_minimum_required(VERSION 2.8.10.20130312)
project(Foo)
add_executable(foo foo.cpp)
target_include_directories(foo PUBLIC
$BUILD_INTERFACE:${Foo_BINARY_DIR}
$INSTALL_INTERFACE
On 2013-03-13 20:59, Matthew Woehlke wrote:
This simple CMakeLists.txt is broken with ninja:
cmake_minimum_required(VERSION 2.8.10.20130312)
project(Foo)
add_executable(foo foo.cpp)
target_include_directories(foo PUBLIC
$BUILD_INTERFACE:${Foo_BINARY_DIR}
$INSTALL_INTERFACE
On 2013-02-25 14:00, Brad King wrote:
On 02/25/2013 01:29 PM, Matthew Woehlke wrote:
On 2013-02-24 10:29, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default. Is there any reason not
to enable
On 2013-02-25 15:02, Brad King wrote:
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
The possibility that first came to mind is where the API depends on
compiler
On 2013-02-19 15:09, Alexander Neundorf wrote:
I don't see where automatically setting ExactCase_FOUND improves over the
current situation.
Right now, as a user of a Find-module you can only rely on the variables as
documented for each Find-module.
This sounds like a bug. Why not just fix
On 2013-02-19 16:21, Alexander Neundorf wrote:
On Tuesday 19 February 2013, Matthew Woehlke wrote:
On 2013-02-19 15:09, Alexander Neundorf wrote:
I don't see where automatically setting ExactCase_FOUND improves over the
current situation.
Right now, as a user of a Find-module you can only
On 2013-02-11 09:06, Brad King wrote:
I think we should drop all that and instead have the includes and defines
usage requirements added at generate time based on the link closure. We
discussed this before, and the reasons for doing it immediately were:
* Ordering of tll() calls relative
Consider this line of CMake code:
string(REGEX REPLACE ^([^.]*)(\..*)?$ \1 BAR ${FOO})
It looks reasonable to me, and works fine on !Windows. However, on
Windows, I get these errors:
Syntax error in cmake code at elided when parsing string
^([^.]*)(\..*)?$
Invalid escape sequence \.
Syntax
On 2012-12-11 08:35, Brad King wrote:
Another idea is to simply not allow both commands to be used on a given
target. Since the new command does not yet exist this cannot break any
existing projects. One must either specify everything by the new command
or everything by the old command.
How
While writing a command to invoke asciidoc, I thought I would use this
little regex replace to get the output file name:
string(REGEX REPLACE ([.][^.]+)?$ .html BAR ${FOO})
However, CMake is throwing this error:
string sub-command REGEX, mode REPLACE regex ([.][^.]+)?$ matched an
empty
On 2012-10-19 10:25, David Cole wrote:
[...] Please try this version of CMake on your projects and report any
issues to the list or the bug tracker. This release candidate will
become the final release for 2.8.10 by the end of October unless
somebody finds and reports a serious issue that needs
99 matches
Mail list logo
