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 o
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 imposs
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 pro
On 2014-12-18 11:30, Ruslan Baratov via cmake-developers wrote:
> You prefer ".cmake.lock", I prefer "cmake.lock", others prefer
> '.lock'/'.cmake'. For me it doesn't really matter. What matter is the
> *standard* cmake name.
FWIW, I do have a slight preference to using a hidden file :-).
> About
On 2014-12-17 16:58, Ruslan Baratov via cmake-developers wrote:
> On 17-Dec-14 21:11, Matthew Woehlke wrote:
>> 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.loc
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
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 migh
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.
>
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
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
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-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&#x
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
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 it,
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 latte
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 pro
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 c
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-04-17 22:23, Ben Boeckel wrote:
On Thu, Apr 17, 2014 at 17:17:21 -0400, Matthew Woehlke wrote:
Alas, the only character that may not appear in a variable name is
'\0'. (And even that is more due to use of raw char* with no length
than intent, I bet.)
Actually, it's all
On 2014-04-13 03:37, Rolf Eike Beer wrote:
Sadly the expression is even expanded when it is quoted as long as it is a
valid variable name. So what you could do is: replace the "x" by a simple
space and then quote the match string, because " Linux" is no valid variable
name.
set(" Linux" Windows
On 2014-02-21 16:34, Ben Boeckel wrote:
Other than , I don't really see a huge burden to not allowing
implicit dereferencing and it is more consistent at that point. In fact,
I'd be willing to say in that we *only* support implicit
dereference, but it may be too hard to detect:
if (${var})
On 2014-02-21 16:00, Ben Boeckel wrote:
On Fri, Feb 21, 2014 at 15:34:44 -0500, Matthew Woehlke wrote:
On 2014-02-21 14:51, Ben Boeckel wrote:
If I made a branch which warned when implicit expansion was done, would
folks be willing to run it over various codebases to see how annoying it
would
On 2014-02-21 14:51, Ben Boeckel wrote:
If I made a branch which warned when implicit expansion was done, would
folks be willing to run it over various codebases to see how annoying it
would be to just remove it altogether?
To be clear, are we talking about in the case of e.g. STREQUAL, or
*ev
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 change
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
vari
On 2014-02-11 17:54, Ben Boeckel wrote:
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
On 2014-02-11 14:49, Ben Boeckel wrote:
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
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 freq
On 2014-02-03 18:13, Alex Merry wrote:
+also inspects header files named ``.`` and ``.`` for
Am I blind, or did you list the same header pattern twice? (I think one
of these was meant to have a '_p'?)
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
ht
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:: cmake
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
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dcc
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() comm
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 i
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 variable:
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-14 14:11, Daniel Pfeifer wrote:
2014/1/14 Matthew Woehlke :
@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
The documentation for both variables
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 PROJECT_VERSION_M
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-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-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, whic
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-referenci
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 t
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 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 loadin
On 2013-12-18 15:13, Mantis Bug Tracker wrote:
Setting CMAKE_JAVA_TARGET_OUTPUT_DIR to the desired output path seems to have no
affect when using NMake as the generator.
Steps to Reproduce:
include(UseJava)
set(CMAKE_JAVA_TARGET_OUTPUT_DIR )
add_jar()
The jar will continue to be placed
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 ye
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-03 11:59, Brad King wrote:
I'd like to avoid new uses of define_property if possible. It
is a legacy from the old builtin documentation system.
Sorry to go off on a tangent, but this triggered a question in my mind...
I have a wrapping utility file that declares some (CMake) helper
On 2013-12-11 20:00, Ben Boeckel wrote:
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 r
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 addit
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" l
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 triv
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 reas
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 d
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 d
On 2013-12-06 15:42, Brad King wrote:
On 12/06/2013 03:11 PM, Matthew Woehlke wrote:
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
re
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 woul
On 2013-12-06 03:28, Marcel Loose wrote:
On 05/12/13 18:27, Matthew Woehlke wrote:
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
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
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 17:33, Daniele E. Domenichelli wrote:
On 11/11/13 17:52, Matthew Woehlke wrote:
On 2013-11-11 05:13, Daniele E. Domenichelli wrote:
WCTS, how does one now unset a variable in parent scope?
I recall some time back there was talk of adding PARENT_SCOPE to
unset(). If set() can no
On 2013-11-11 12:17, Nils Gladitz wrote:
On 11.11.2013 17:38, Matthew Woehlke wrote:
What else can you do? Until you re-run CMake, there is no way to know
how many edges need to be executed. Even if ninja were to show the
maximum possible number of edges, that could be too small e.g. because
On 2013-11-11 05:13, Daniele E. Domenichelli wrote:
I've pushed a patch to the set_emptyvar_PARENT_SCOPE topic.
This patch introduces a new policy (CMP0040) to control the behaviour of
set(var "" PARENT_SCOPE)
the OLD behaviour is to unset the "var" variable in the parent scope
the NEW beh
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 should
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-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 = Specify a makefile generator.
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 ?
Y
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 conf
On 2013-10-22 07:15, Ian Liu Rodrigues wrote:
Below is a list of some things that I would love to see on CMake 3.0:
* Possibility to wrap long lines, maybe with a backslash at the end
of the line;
I guess you mean in single string arguments specifically? I can't think
of other cases wher
On 2013-10-21 13:36, Alexander Neundorf wrote:
On Friday 11 October 2013, Brad King wrote:
Hi Folks,
I think the time has come for a major version number bump to go with
some major updates. I propose to skip preparing 2.8.13 in 'master'
and go straight to 3.0.0.
Potential changes motivating a
On 2013-10-18 10:47, Rolf Eike Beer wrote:
Am Freitag, 18. Oktober 2013, 10:42:19 schrieb Brad King:
So the block can be (untested):
if("x${arg}" STREQUAL "xBUILTIN_TYPES_ONLY")
Ah, horrid crap! :P
Any chance that this would not do what is expected from it?
if (arg STREQUAL "BUILTIN_TYPES
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 ha
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-10-10 22:02, J Decker wrote:
is there a wish list of features for 3.0?
* offer commands available with 'cmake -e ' as direct commands
(I think that's the option... copy_if_different ?) or did I just not
find the alias?
What 'cmake -e' commands are not available at CMake configur
On 2013-09-25 16:14, Eric Noulard wrote:
2013/9/25 Matthew Woehlke :
On 2013-09-25 12:18, Eric Noulard wrote:
$ cmake --help-variable CMAKE_
If you at the end of this line, aren't you trying to complete a local
file name 'L'?
Yes and in fact it "restart" the
On 2013-09-25 12:18, Eric Noulard wrote:
$ cmake --help-variable CMAKE_
If you at the end of this line, aren't you trying to complete a
local file name 'L'? Does it work if you escape the '<'?
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www
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 path
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 yield
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 doe
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 t
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 wa
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 sam
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-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 build-t
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 featu
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 t
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 q
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 c
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 ha
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-19 19:47, Wojciech Knapik wrote:
I you ever put "junk files" with, say, a .cpp extension in a source tree
of a C++ project, you're the only one to blame.
This is not unusual at all. I'm often in the situation where I have
source files for classes that are works in progress, tangent
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 p
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 c
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)
add_custom_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 wi
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
1 - 100 of 128 matches
Mail list logo
