>From (at least) CMake 2.8.9 to CMake 3.4, this CMakeLists.txt
---
cmake_minimum_required(VERSION 2.8.9)
project(bar)
include(CMakeParseArguments)
macro(foo)
set(_options )
set(_oneValueArgs FOO)
set(_multiValueArgs )
cmake_parse_arguments(_FOO1 "${_options}"
On 02/11/2015 20:53, Brad King wrote:
> LGTM. Please merge to 'next' for testing.
Done. Thanks.
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake
Dear all,
Please review the topic FindGTK2_GTK2_TARGETS:
Previously, when GTK2_USE_IMPORTED_TARGETS was enabled, the
GTK2_LIBRARIES variable was still filled with the paths to the
libraries, and only the GTK2_XXX_LIBRARY variables contained the
imported targets.
This patch changes the behaviour
Hello Brad,
On 12/10/2015 17:00, Brad King wrote:
>> I understand this is a quite controversial module, but I would like to
>> stress that this is something that can already be done using CMake just
>> by executing file(DOWNLOAD) and include(), this module just makes it
>> easy to do it. Whether
Hello Brad,
thanks for your comments.
On 08/10/2015 17:48, Brad King wrote:
> I wish you had come asking about this proposal to hold discussion
> before going through all the work to implement this.
We've been successfully using this module for about 2 years now and we
will continue to use it
On 06/10/2015 19:25, Brad King wrote:
> On 10/06/2015 12:20 PM, Daniele E. Domenichelli wrote:
>> I updated the topic according to your comments. The new commit is this:
>>
>> FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
>> https://cmake.org/gitweb?p=stage/cmake
Hello all,
Please review the "IncludeUrl" topic[1] that adds a new "IncludeUrl"
module. This module adds the include_url command that is useful to
download and include other CMake modules from a given url.
[1]https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/IncludeUrl
The
Hello,
Starting with some recent update on my system that updated sigc++ from
2.4.0 to 2.6.1, I noticed that a few GTK2Targets tests depending on
sigc++ are failing.
According to the sigc++ changelog, starting with version 2.5.1, sigc++
requires c++11 enabled, hence this patch.
FindGTK2:
On 22/12/14 19:38, Rolf Eike Beer wrote:
About the FindPkgConfig macros documentation, what is that is not clear?
It's not about the documentation of that module, but where I need to hack it
into the module. The code is quite a bit of indirections, I guess I would
need
to do this
Is there a way to separate components for a library with a SONAME and
the link?
For example if I do something like this:
add_library(foo ${foo_SRCS})
set_target_properties(foo PROPERTIES SOVERSION 1)
install(TARGETS foo
LIBRARY DESTINATION lib)
This will install
Hello all,
Please review the topic install_CMAKE_INSTALL_RELATIVE.
install: Add CMAKE_INSTALL_RELATIVE variable
http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=3b57fa0
This patch adds a a variable CMAKE_INSTALL_RELATIVE to install files in
CMAKE_INSTALL_PREFIX using relative path,
Hello Eike,
On 22/12/14 16:39, Rolf Eike Beer wrote:
What I would like to get is the following: when a list of libraries and
directories is returned by PkgConfig then for every of these libraries the
absolute path to the library is determined using find_library() using the
given
On 01/12/14 16:03, Brad King wrote:
LGTM. Please also add a
Help/release/dev/ExternalProject_TEST_EXCLUDE_FROM_MAIN.rst
file with a release note advertising the feature.
Done... squashed everything in one commit:
* ExternalProject: Add TEST_EXCLUDE_FROM_MAIN option
On 10/11/14 15:18, Brad King wrote:
However, the test does not fail for me even without the fix. I
think for 3.1.0-rc2 I will take this fix but not the test yet.
Please extend the topic to revise the test:
The test fails for me on a ubuntu precise chroot using gcc 4.6.3 (I
wasn't able to
On 10/11/14 16:49, Brad King wrote:
Thanks. Please rename the 'foo' and 'bar' libs to 'case5Foo' and
'case5Bar' to avoid conflict with other cases in the future.
Done:
Rename the 'foo' and 'bar' libs to 'case5Foo' and 'case5Bar'
Hello,
Please review topic fix_link-line-dedup_regression:
Fix regression in link order introduced by the link-line-dedup topic
Some compilers will fail linking if an executable is linking to a
library that is not used and a static library that uses the shared one.
This patch reverse the
Hello,
Sorry for resuming an old thread, you can read the original thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8680/
This topic was reviewed and merged into next, but there were some issues
in the unit tests with Ninja and with parallel builds.
I finally
On 03/11/14 16:02, Brad King wrote:
My only nitpick is that the work was spread out over so long
that the author dates are a little confusing. Please reset
them and then merge to 'next'.
Done. Thanks!
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake
Hello Brad,
On 29/10/14 14:38, Brad King wrote:
In the updated docs for CMAKE_ARGS, CMAKE_CACHE_ARGS, and
CMAKE_CACHE_DEFAULT_ARGS, the intro line now needs a period.
The new RunCMake.ExternalProject test looks good. However, it
does not verify that the external project actually builds
Hello Brad,
Sorry for the delay.
On 22/10/14 17:18, Brad King wrote:
How about a new option like CMAKE_CACHE_DEFAULT_ARGS for that?
I just pushed a new ExternalProject_CMAKE_CACHE_DEFAULT_ARGS topic, can
you please review it?
Cheers,
Daniele
--
Powered by www.kitware.com
Please keep
On 28/10/14 18:01, Brad King wrote:
Please rebase on those. You should find it much easier to add
more detail to the documentation of each option.
Done, thanks.
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 20/10/14 15:52, Brad King wrote:
On 10/16/2014 11:26 AM, Daniele E. Domenichelli wrote:
#[CMAKE_ARGS args...]# Arguments to CMake command line
#[CMAKE_CACHE_ARGS args...] # Initial cache arguments, of the form
-Dvar:string=on
So, from what I understand, The first
Hello all,
I have question about CMAKE_ARGS and CMAKE_CACHE_ARGS, and I'm not sure
if this is the intended behaviour or not...
From the documentation:
#[CMAKE_ARGS args...]# Arguments to CMake command line
#[CMAKE_CACHE_ARGS args...] # Initial cache arguments, of the form
On 04/08/14 20:35, Brad King wrote:
Please also add a check that the value given to the INSTALL_PREFIX
option passes if(IS_ABSOLUTE). It does not make sense to have a
relative value here.
Done and merged to next.
Thanks,
Daniele
--
Powered by www.kitware.com
Please keep messages
Hello Brad,
On 30/07/14 15:32, Brad King wrote:
Thanks. While reviewing the commits in 'next' again I realized
that assuming paths are relative to CMAKE_BINARY_DIR may not be
correct. Some projects may be nested inside others, and the
CMAKE_BINARY_DIR may not be the proper location for a
Hello Brad,
On 30/07/14 15:32, Brad King wrote:
Thanks. While reviewing the commits in 'next' again I realized
that assuming paths are relative to CMAKE_BINARY_DIR may not be
correct. Some projects may be nested inside others, and the
CMAKE_BINARY_DIR may not be the proper location for a
On 28/07/14 16:11, Brad King wrote:
On 07/25/2014 10:00 AM, Daniele E. Domenichelli wrote:
Sorry if I insist, but I still don't understand why not allowing to be
able to use CMakePackageConfigHelpers for the build tree
I didn't mean to imply that the patch is not acceptable. After
[Changing subject in order to keep the conversation separate]
On 23/07/14 20:39, Brad King wrote:
Since you were asking if CMake misses some important feature, I believe
that a very useful feature to have would be to be able to have an option
for the install(FILES/PROGRAMS/DIRECTORY) command
On 23/07/14 20:39, Brad King wrote:
Returning to CMakePackageConfigHelpers, I work on several projects
that provide one pkgConfig.cmake file in the build tree and one
in the install tree. They are generated by hand. I do not use
CMakePackageConfigHelpers. IMO it is good for getting projects
On 21/07/14 21:04, Stephen Kelly wrote:
Can you give a more-concrete example of what the problem is?
The project is supposed to work both from build tree (using
export(TARGETS)) and from the install tree (using install(EXPORT)).
Your example is too abstract. What is the meaning of the
On 22/07/14 10:53, Stephen Kelly wrote:
Daniele E. Domenichelli wrote:
The first case is a folder that is appended to CMAKE_MODULE_PATH, and
that containing CMake files that can optionally be included by projects
using this package.
I still find this an odd user interface.
You provide
On 22/07/14 13:44, Stephen Kelly wrote:
Does this mean that if I set the PACKAGE_DIR environment variable to
the CMAKE_BINARY_DIR of my package, CMake will look into these folders
as well?
No, I don't think so. You would have to set it to the exact dir afaik.
Actually I tested it, and CMake
On 17/07/14 16:33, Brad King wrote:
+# .. command:: configure_package_config_file
+#
+# Create a config file for a project::
The definition of the command should be in an indented block so
that reST knows it is part of the explicit markup block.
I indented the whole command block, can you
On 21/07/14 14:23, Stephen Kelly wrote:
Can you give a more-concrete example of what the problem is?
I have a project that is similar to this small example:
--- CMakeLists.txt
cmake_minimum_required(VERSION 2.8.12)
project(FOO NONE)
set(FOO_VERSION 0.0.1)
On 21/07/14 16:17, Brad King wrote:
On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote:
I indented the whole command block, can you please have a look if that's
what you meant? Or is it just the brief description of the command
that should be indented?
I think just the signature summary
Hello all,
Please review the topic CMakePackageConfigHelpers_build_tree.
This patch adds an option BUILD_TREE to configure_package_config_file.
At the moment it is complicated to generate config files both for
install and build tree, usually combined with export(TARGETS) and
install(EXPORT),
Hello all,
Can anyone with OSX and Xcode check if this commit is correct?
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e475c067
I have no way to test it, but by looking at the code, it looks to me
that the name should be Xcode instead of XCode...
Thanks,
Daniele
--
Powered by
On 15/07/14 15:07, Brad King wrote:
Yes, please merge for testing in 'next'.
Done, Thanks.
Cheers,
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake
for testing this.
What is your opinion? How should I use it? Should I just use the long
version?
Cheers,
Daniele
[1]http://sphinx-doc.org/latest/ext/intersphinx.html
[2]http://cmake.org/cmake/help/v3.0/
From 2f06136d7b18f14899b8bb7238837d877f1e2328 Mon Sep 17 00:00:00 2001
From: Daniele E
Hello all,
Please review the topic ExternalProject_labels.
---
ExternalProject: Set LABELS property to targets
his is useful for using CDash subprojects.
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=8810ddb3b710abf222f23ae96ac025beae63d812
---
ExternalProject: Set FOLDER
Hello all,
Please review the topic ExternalProject_VCS-quiet.
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2dad1c143cfee60eadcf1bee5faa47efed89a31a
ExternalProject: Find VCS packages quietly
This keeps the VCS packages out from FeatureSummary output, unless the
On 27/03/14 16:34, Brad King wrote:
Yes, but let's do only one change to ExternalProject per day so
we can see how the tests do.
Thanks for merging the other patch.
I just rebased and merged this one to next now.
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and
Hello all,
Sorry for bringing up an old thread, you can find the original thread
here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8658
I pushed the topic again with no changes (just a rebase), I've been
using it for a while with no issues at all.
Is it ok to merge it to
Hello again,
Sorry for bringing up another old thread, you can find the original
thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8837
I pushed the topic again with no changes (just a rebase), I've been
using it for a while with no issues at all.
Is it ok to merge
On 27/03/14 16:53, Brad King wrote:
Actually you don't need to parse the arg ahead of time.
The ALL option to add_custom_target just tells it to
*not* set the EXCLUDE_FROM_ALL target property. Instead
you can leave out ALL, parse the args as normal, and
then add
set_property(TARGET ...
On 27/03/14 18:50, Brad King wrote:
On 03/27/2014 12:24 PM, Daniele E. Domenichelli wrote:
+ if(;${ARGN}; MATCHES ;EXCLUDE_FROM_ALL;([^;]*);)
+set(exclude_from_all ${CMAKE_MATCH_1})
+ endif()
+ if(NOT exclude_from_all)
+set(all ALL)
+ endif()
Sorry, I made 2 force-pushes (after
On 27/03/14 19:45, Brad King wrote:
On 03/27/2014 02:35 PM, Brad King wrote:
Please take a look at the failure on the continuous test submissions.
fatal: Couldn't find remote ref origin/master
fatal: The remote end hung up unexpectedly
Is there a particular version requirement on Git?
I
On 16/03/14 23:49, Christoph Grüninger wrote:
I'd like to add additional paths for pkg_check_modules similar to
find_program:
[PATHS path1 [path2 ... ENV var]]
Daniele would you mind to add such a feature? Or are there any
objections if I do it myself?
No objections if you want to add it
On 11/03/14 14:51, Brad King wrote:
Please add test cases for the FindPkgConfig interface and argument
parsing errors. The test can just fake the location of pkg-config
with a dummy if necessary.
I added some unit test. I'm not done yet, but I would like to see if it
works on all the
On 11/03/14 14:51, Brad King wrote:
Also the hunks:
+if(UNIX)
+ string(REPLACE \\: ; _path ${_path})
+endif()
should not be necessary because TO_CMAKE_PATH already does that.
It looks like TO_NATIVE_PATH does not do the reveres though so that
explicit
On 06/03/14 17:25, Brad King wrote:
Am I supposed to add documentation for the variable
PKG_CONFIG_USE_CMAKE_PREFIX_PATH, that is checked by this patch?
It looks like you've updated the docs further to use the variable
directive. Good. Do you mind flipping the order of the patches
to
if (debian) add lib/arch
elseif (64 bit or unknown) add lib64
add lib
That looks good except for FIND_LIBRARY_USE_LIB64_PATHS.
Fixed. Now the logic is
if (debian) add lib/arch
elseif (FIND_LIBRARY_USE_LIB64_PATHS) add lib64
add lib
The text defining the command needs to be
Dear CMake developers,
Follow up to this thread:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8369
Please review the topic FindPkgConfig_Extend-PKG_CONFIG_PATH.
FindPkgConfig: Extend PKG_CONFIG_PATH using CMake variables
Use CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH, and
On 03/03/14 17:21, Brad King wrote:
Please add a Tests/RunCMake/FeatureSummary test to cover at least the
new error messages.
Done, added unit tests for all the WHAT argument cases.
Cheers,
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Dear CMake developers,
Please review the topic FeatureSummary_combine_WHAT_values.
This patch allows to combine and reorder values for the WHAT option in
FeatureSummary.
For example it is now possible to do
feature_summary(WHAT ENABLED_FEATURES
DISABLED_FEATURES)
On 15/01/14 15:29, Brad King wrote:
On 01/14/2014 11:47 AM, Daniele E. Domenichelli wrote:
Updated the topic to behave in this way. Can you please review it again?
Please update the comment introducing __LAST_LIBDIR_DEFAULT to explain
that it is the default we compute from
On 15/01/14 16:27, Brad King wrote:
On 01/15/2014 10:11 AM, Daniele E. Domenichelli wrote:
+get_property(_libdir_set CACHE PROPERTY CMAKE_INSTALL_LIBDIR SET)
That should be
get_property(_libdir_set CACHE CMAKE_INSTALL_LIBDIR PROPERTY TYPE)
Is there any issue in using
get_property
On 15/01/14 20:37, Brad King wrote:
This topic looks good to me. Please merge to 'next' for testing.
Merged.
Thanks,
Daniele
--
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
On 13/01/14 16:51, Brad King wrote:
On 01/13/2014 10:23 AM, Daniele E. Domenichelli wrote:
Can I store CMAKE_INSTALL_PREFIX in an internal cached variable, check
if it was changed since last run (i.e. CMAKE_INSTALL_PREFIX_OLD !=
CMAKE_INSTALL_PREFIX), check if the value is the default one
Hello,
Please review the topic GNUInstallDirs_debian-multiarch-fix
GNUInstallDirs: Fix CMAKE_INSTALL_LIBDIR on Debian
When not installing in /usr (i.e. /usr/local) on Debian/Ubuntu, the
multiarch path is not in ldconfig path, and therefore libraries cannot
be found, unless the user manually
On 10/01/14 21:19, Alexander Neundorf wrote:
Should the full version 1.2.3 be put into PROJECT_VERSION or
PROJECT_VERSION_STRING ?
Both forms are used in different places in cmake.
I usually consider PROJECT_VERSION = Major.Minor.Patch and
PROJECT_VERSION_STRING as a customizable string that
On 13/01/14 15:34, Brad King wrote:
This hunk:
-if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
removes the guard that avoids doing all the default-computing
logic when there is already a value. In this hunk:
+set(CMAKE_INSTALL_LIBDIR ${_LIBDIR_DEFAULT} CACHE PATH object code
libraries
On 13/01/14 15:57, Brad King wrote:
On 01/13/2014 09:47 AM, Daniele E. Domenichelli wrote:
The problem comes when you change the CMAKE_INSTALL_PREFIX:
When you run cmake (with no -DCMAKE_INSTALL_PREFIX=... argument),
CMAKE_INSTALL_PREFIX is set to /usr/local, and the CMAKE_INSTALL_LIBDIR
On 18/12/13 17:52, Brad King wrote:
Maybe adding a function
ExternalProject_Add_Dependencies(name step targets)
that internally calls both add_dependencies and add_custom_command(APPEND)?
Yes, I think that makes sense. Perhaps
ExternalProject_Add_Step_Dependencies
?
Ok for the
On 20/12/13 14:35, David Cole wrote:
Existing calls to ExternalProject_Add must continue to work as they
were before your topic. As long as you leave *most* of them alone for
testing purposes, you should be ok. Ideally, for new functionality you
would write a new part of the test, with new
On 04/12/13 10:15, Daniele E. Domenichelli wrote:
Please review the topic ExternalProject_exclude-from-all.
I added a second part to the patch to ad an EXCLUDE_FROM_ALL argument to
ExternalProject_Add
If this is set, the all target will not depend on the external project
This might be useful
On 05/12/13 14:56, Brad King wrote:
Without a policy project authors will not be warned about the change in
behavior that would be caused by bumping cmake_minimum_required(VERSION).
Ok, let's assume that we add a C++ implementation with a CMP policy
that does
* OLD policy = SKIP_EMPTY
*
On 04/12/13 14:28, Brad King wrote:
I think the option should be called EXCLUDE_FROM_MAIN or something
without ALL in it. Otherwise it looks related to the EXCLUDE_FROM_ALL
settings used for the make all CMake builtin target.
Ok, changed to EXCLUDE_FROM_MAIN.
Cheers,
Daniele
--
Powered
On 03/12/13 17:59, Brad King wrote:
Why does CMAKE_PARSE_ARGUMENTS_DEFAULT_SKIP_EMPTY need to be an
inherited directory property instead of a variable? Both have
essentially the same scope and variables are much more common.
I'd like to avoid new uses of define_property if possible. It
is a
On 02/12/13 18:06, Brad King wrote:
Please extend the topic with updates to the test suite to cover the
new option.
[...]
Also please add a RunCMake.ExternalProject test with a case to
verify that this message appears:
[...]
Also remove extra indentation from the above-quoted line.
Done
On 04/12/13 14:40, Brad King wrote:
The RunCMake.CMakeParseArguments test fails on the continuous builds.
Please take a look.
Should be fixed now.
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please
On 04/12/13 14:20, Brad King wrote:
The module can be provided as an empty file except for documentation.
Any project including it will expect to be able to call cmake_parse_arguments
afterwards, which they will be able to since it will be a builtin command.
With the policy handling
On 02/12/13 22:57, Brad King wrote:
The function() and macro() commands rename any existing command
of the same name to one with a leading underscore. This was added
long ago for use as local debugging and never really finished.
It is not documented behavior.
Thanks! This actually explains
On 03/12/13 15:43, Brad King wrote:
On 12/03/2013 09:42 AM, Brad King wrote:
After this is worked out please rebase everything on master and
squash the topic down to avoid the break- fix-compatiblity
sequence.
Also, Steve added a Module.CMakeParseArguments test to the topic.
Wouldn't that
On 03/12/13 15:53, Brad King wrote:
Thanks. Please squash it so that the topic looks like you got this
all right the first time. Also convert Steve's test case to a
RunCMake test and perhaps add some error case checking if needed too.
Done, I'm not sure if you want to squash even more...
On 03/12/13 21:34, Ben Boeckel wrote:
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
a crash.
Yep. For once, not caused by me :).
Bisect points to
commit bf203c8f8e4a6ad4f642b2653f8abca563484889
Author: Daniele E. Domenichelli daniele.domeniche...@iit.it
Date: Thu Nov 14 11:42:35 2013 +0100
CMakeParseArguments: Add workaround for compatibility with CMake
Any other comment on this topic?
Can I go on and merge it to next?
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
On 14/11/13 18:34, Daniele E. Domenichelli wrote:
I updated the CMakeParseArguments_EmptyArgs topic, so that it will work
properly with cmake 3.0.0 (after the branch set_emptyvar_PARENT_SCOPE
topic is merged) and with older releases (I had to add a workaround for
that)
Can you please review
On 25/11/13 18:04, Jean-Christophe Fillion-Robin wrote:
After copying the ExternalProject.cmake in the Module directory of the
CMake installation I used for daily work, I didn't see any issue / side
effect.
Considering the external projects I am dealing with always specify the
SHA1, I
On 22/11/13 19:03, Brad King wrote:
On 11/22/2013 12:28 PM, David Cole wrote:
So I would add to the documentation saying that typically, only the
download and update steps ought to be considered as independent step
targets.
Would it make sense to only allow it for specific steps, or to
On 19/11/13 16:34, Brad King wrote:
* The STATUS variable is not set, therefore it is not useful;
* The faulty downloaded file is not removed.
So I believe that there is no way to stop CMake, unless you perform
another hash check.
The this-SetError/return false logic for these errors should
Hello,
Please review the topic ExternalProject-independent-step-targets.
When adding step targets using ExternalProject_Add_StepTargets, the
STEP_TARGETS argument, or the EP_STEP_TARGETS property, ExternalProject
sets all the dependencies for the main project to that target. Due to
this, the
Hello all,
After calling file(DOWNLOAD EXPECTED_HASH) I cannot find a way to check
if the hash is correct.
* The command gives an error, but not fatal, therefore the processing
will continue;
* The STATUS variable is not set, therefore it is not useful;
* The faulty downloaded file is not
Hello,
Please review the topic ExternalProject_GitUpdate
ExternalProject handles git remote branches by commit hash. Due to this,
the git repository ends in detached states, and local commits are discarded.
This patch uses git pull --rebase for remote branches instead of git
checkout. If there
On 15/11/13 17:41, Brad King wrote:
On 11/15/2013 03:27 AM, Daniele E. Domenichelli wrote:
So I believe that some more documentation would be helpful... If you
agree, I can write it...
Fine with me! One reason we changed to the rst-formatted documentation
is to make it easier to write
On 18/11/13 16:39, Robert Maynard wrote:
I am understanding properly that the last paragraph properly, this will
fix the problem that setting GIT_TAG to a named branch doesn't keep the
branch up to date with the remotes version of the branch?
Yes, exactly... setting GIT_TAG to master (or any
Hello Brad,
On 18/11/13 18:44, Brad King wrote:
Please place the :: starting a literal block at the end of
the previous paragraph when the block is part of the paragraph.
[...]
Also please use ``inline-code-example`` syntax for text referring
to constructs from the literal blocks.
[...]
Hello,
I updated the CMakeParseArguments_EmptyArgs topic, the new behaviour is
now decided as follows:
* If CMAKE_MINIMUM_REQUIRED_VERSION 2.8.13, the default behaviour is
to skip empty arguments, otherwise the default behaviour is to keep
them.
* Using the
On 08/11/13 17:54, Daniele E. Domenichelli wrote:
foo(FOO foo)
Obviously it was supposed to be
set(FOO foo)
Sorry...
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic
On 05/11/13 20:51, Alexander Neundorf wrote:
I don't know if this is to be considered a change of behaviour though,
but I'd rather consider it a bug, and I would like to see it fixed in
the next bugfix release... what do you think?
cmake_parse_arguments() is used in quite a few places in the
Hello all,
Current implementation of cmake_parse_arguments skips empty arguments.
For example:
cmake_parse_arguments(OPTION SINGLE MULTI ${ARGN})
with ARGN that is set using something like:
args SINGLE more args # (args;SINGLE;;more args)
args SINGLE # (args;SINGLE;)
it will fail
Hello all,
I have another issue with ExternalProject.
If I add 2 external projects (A and B), with B DEPENDS=A, and
STEP_TARGETS=update, I expect to be able to update B without updating,
building and installing A, since just updating the code is obviously not
dependent.
I tried to look at
Hello all,
FindPkgConfig does not support the CMAKE_PREFIX_PATH variable.
This is because pkg-config uses the PKG_CONFIG_PATH and does not know
anything
about CMAKE_PREFIX_PATH.
As a consequence, pkg-config packages built and installed in a non standard
directory using ExternalProject, cannot be
On 18/10/13 14:07, Brad King wrote:
If you want to parse it yourself you can follow the state machine
convention used in Modules/FortranCInterface and in the C++ implementation
of many commands (look for doing). Is there a drawback to using
CMakeParseArguments?
Not that I'm aware of, but
Hello Brad,
On 25/09/13 17:01, Brad King wrote:
I noticed that on some builds, all the tests for GTK2Targets suddenly
disappeared:
londinium.kitware: http://open.cdash.org/viewTest.php?buildid=3039037
TheGibson.kitware: http://open.cdash.org/viewTest.php?buildid=3039001
Is it my fault or
On 02/10/13 16:23, Brad King wrote:
You could also add a RunCMake/CheckModules case to check the
error conditions (bad args and bad language).
Done!
Cheers,
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
On 23/09/13 17:50, Brad King wrote:
One could add an optional extra parameter to specify the language
to be used for the check (C or CXX). However, we should do something
that could be re-used in the similar modules too. Would you mind
surveying all the check signatures we currently have and
On 24/09/13 14:18, Brad King wrote:
On 09/24/2013 03:50 AM, Daniele E. Domenichelli wrote:
It looks like that the signatures are not very consistent...
Yes, but they all have room for optional keyword-based arguments
following the main arguments. How about
CHECK_STRUCT_HAS_MEMBER
On 24/09/13 16:44, Brad King wrote:
On 09/24/2013 09:46 AM, Daniele E. Domenichelli wrote:
I pushed a commit to the CheckStructHasMember_CXX topic, can you review
it?
You can simplify the implementation using ${ARGN} to get the arguments
beyond those explicitly named in the signature.
You
1 - 100 of 121 matches
Mail list logo
