The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12986
==
Reported By:Dave Abrahams
Assigned To:
On Mon, Feb 20, 2012 at 1:53 PM, David Cole david.c...@kitware.com wrote:
On Mon, Feb 20, 2012 at 1:47 PM, Clinton Stimpson clin...@elemtech.comwrote:
On Feb 20, 2012, at 8:21 AM, David Cole wrote:
On Mon, Feb 20, 2012 at 9:25 AM, Brad King brad.k...@kitware.com wrote:
On 2/18/2012 5:47
On 2/20/2012 5:43 PM, Brad King wrote:
The new find_package option will be called CONFIG, please.
Another possibility is to require the mode keywords to come as the first
argument, before the package name, just like many other commands:
find_package(CONFIG Foo)
That will clearly
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12987
==
Reported By:Emmanuel Blot
Assigned To:
I've created a group called Temporarily Problematic Nightly on the
CMake dashboard today.
It's for dashboards which chronically fail for reasons beyond our control.
The two submissions that I sent to that group are using the Visual
Studio 11 generator and the VS 11 Developer Preview from MSFT.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12991
==
Reported By:Christopher Sean Morrison
Assigned
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12992
==
Reported By:Christopher Sean Morrison
Assigned
On Friday 17 February 2012, Alexander Neundorf wrote:
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
Actually I expected I would prefer this over the fixed names, but now
that I've done it and look at what Config.cmake.in file I have to
On Monday 20 February 2012, Alexander Neundorf wrote:
On Monday 20 February 2012, Brad King wrote:
...
(2) Add the explicit MODULE and CONFIG mode keywords. Warn if they
are used and the current minimum CMake version is not = 2.8.8 so that
people do not add them in places that will break
On 2/21/2012 3:17 PM, Alexander Neundorf wrote:
On Friday 17 February 2012, Alexander Neundorf wrote:
So, I'm not that sure that using PACKAGE instead of CONFIG is really
better (the branch I pushed uses PACKAGE, but I could change this again).
Ok, so we stay here with PACKAGE, also in the
On Tuesday 21 February 2012, Alexander Neundorf wrote:
On Monday 20 February 2012, Alexander Neundorf wrote:
On Monday 20 February 2012, Brad King wrote:
...
(2) Add the explicit MODULE and CONFIG mode keywords. Warn if they
are used and the current minimum CMake version is not =
This macro does this:
macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; }
int main() { return somefunc();} ${_RESULT}
# Some compilers do not fail with a bad flag
FAIL_REGEX unrecognized .*option
Rolf Eike Beer wrote:
This macro does this:
macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; }
int main() { return somefunc();} ${_RESULT}
# Some compilers do not fail with a bad flag
FAIL_REGEX
Stephen Kelly wrote:
Hi,
In the last few days something changed to make the GenerateExportHeader
GCC version check fail:
http://open.cdash.org/buildSummary.php?buildid=2016288
Any idea what would cause that? It must be one of these:
Stephen Kelly wrote:
Rolf Eike Beer wrote:
This macro does this:
macro(_check_cxx_compiler_attribute _ATTRIBUTE _RESULT)
check_cxx_source_compiles(${_ATTRIBUTE} int somefunc() { return 0; }
int main() { return somefunc();} ${_RESULT}
# Some compilers do not fail
Anyway just to answer myself, I managed to solve all my problems.
Now I first generate at cmake file a file with some paths, and from
these paths I generate all the targets that I need.
I also create a list with all the targets to make it easy from other
targets to depend on them.
Here below
I want to be able to have this simple translation between full path and
filename.
For example = /very/long/path/file.py - file.py
So I did this quite ugly function:
function (get_filename FULLPATH)
string(REPLACE / ; p2list ${FULLPATH})
list(REVERSE p2list)
list(GET p2list
I tried this out with VS 2010 SP0 Win64. Here's my CMakeLists:
cmake_minimum_required(VERSION 2.8)
project(Test CXX)
file(WRITE foo.h //Some Foo Header )
file(WRITE foo.cpp int main(int argc, char** argv) { return 0; }\n)
file(WRITE foo.txt This is the foo text file (simulated
On 02/21/2012 01:39 PM, Rolf Eike Beer wrote:
get_filename_component()
Eike
--
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:
Can you clarify your setup just a bit?
Do you have two ways you configure the build tree, once as Dynamic and
once as Static libraries? And you are building both at the same time?
Or
Are you are calling add_library() twice with the same input files but
specifying SHARED on one of
Hi -
Actually, I have two calls to add_library, so they are in two projects, but
ONE solution. They are built simultaneously by the BUILD_ALL target
Kevin
From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com]
Sent: Tuesday, February 21, 2012 9:06 AM
To: Kevin
I'm not sure why there would be a conflict on the generated files
(unless you are generating them at Build time rather than at CMake
time), but you can probably solve the issue by making one version of the
Library depend on the other version, thus preventing them from building
at the same time.
Yes, for clarity, we do generate the files at build time, not cmake time.
Kevin
From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com]
Sent: Tuesday, February 21, 2012 9:14 AM
To: Kevin Schmidt; cmake@cmake.org
Subject: RE: [CMake] Shared intermediary files
I'm not
If possible, you might want to see about doing all the generation at
CMake time. That should allow you to still build in parallel, unless
you need them to be generated differently for each one (in which case,
you should probably try to generate them in a subdirectory specific to
each target).
On Mon, Feb 20, 2012 at 4:07 PM, Kevin Schmidt ke...@eyesopen.com wrote:
Hello,
I’m in the process of converting over a large, monolithic tree with many
libraries from a custom build solution over to cmake. So far, we’ve loved
it. I am wondering about others’ solutions to a problem we
Hi all.
I was wondering if someone ever have used CMake to configure a .NET
project, where one need to add References in:
Common Properties - Framework and References
I need to locate some .dll-files from a .NET API and add those as
references to a project to be able to build against it.
I
I'm pretty sure that CMake does not directly support .NET projects. Here, we
handle the csharp projects in visual studio and then use the
include_external_msproject stuff to pull them in.
In our case, we had to apply a patch to get it working correctly. (see:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a
directory somewhere.
And I did something like:
get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)
install(
DIRECTORY
Use:
DESTINATION ${PROJECT_NAME}
instead of the full path you're trying to use.
If you use a full path in a CMake install rule, then CPack does not put it
inside the directory that NSIS packs up to build the installer... If you
use a non-full path, then for make install it gets put under
2012/2/21 Andrea Crotti andrea.crott...@gmail.com:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:
get_filename_component(userprofile
Hi,
I'm using Visual Studio as my generator for my CMake projects. As of right
now, I make my tests depend on the libraries they test. So for example,
tests named:
test_thingA
test_thingB
will all depend on library:
libfoo.lib
When I build target libfoo in visual studio, it would be nice to
On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote:
Hi,
I'm using Visual Studio as my generator for my CMake projects. As of right
now, I make my tests depend on the libraries they test. So for example,
tests named:
test_thingA
test_thingB
will all depend on
On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com wrote:
On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote:
Hi,
I'm using Visual Studio as my generator for my CMake projects. As of
right now, I make my tests depend on the libraries they test. So for
On Tue, Feb 21, 2012 at 1:51 PM, Robert Dailey rcdai...@gmail.com wrote:
On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com wrote:
On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com wrote:
Hi,
I'm using Visual Studio as my generator for my CMake projects. As
On Tue, Feb 21, 2012 at 1:15 PM, David Cole david.c...@kitware.com wrote:
On Tue, Feb 21, 2012 at 1:51 PM, Robert Dailey rcdai...@gmail.com wrote:
On Tue, Feb 21, 2012 at 12:37 PM, David Cole david.c...@kitware.com
wrote:
On Tue, Feb 21, 2012 at 1:27 PM, Robert Dailey rcdai...@gmail.com
An possible alternative could be to associate one or more labels to your
tests, then you should be able to run a specific subset of the test suite.
See
http://www.cmake.org/cmake/help/ctest-2-8-docs.html#opt:-Lregex--label-regexregex
and
2012/2/21 Robert Dailey rcdai...@gmail.com:
I apologize if I sounded like your suggestion wasn't meaningful or useful. I
would much rather prefer to do it how you suggest (running all tests), but
this leaves me with some concerns:
If the developer is running all unit tests on their local
On 02/21/2012 06:25 PM, Eric Noulard wrote:
2012/2/21 Andrea Crottiandrea.crott...@gmail.com:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:
Actually, a correction:
Looks like the VS_DOTNET_REFERENCES target property is in CMake 2.8.7 already.
$ cmake --help-property VS_DOTNET_REFERENCES
cmake version 2.8.7
VS_DOTNET_REFERENCES
Visual Studio managed project .NET references
Adds one or more
Hi Aaron,
thank you very much für your analysis. we are currently using cmake, ver
2.8.2.
the effect disappears with cmake 2.8.7. so we have to go for an upgrade.
/thanks again and best regardsWalter
Von:aaron.mead...@thomsonreuters.com
An: walter.schw...@dzbank.de,
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 82c3726537c24183459270355db507a638ee07e1 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 63152d002f40c9426845246aef04636ce416e72c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ae376fb0a499baf6e758ebfd1b71104069da700f (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via e1a6c9b9a1affb846d997fcf19dc90dbc79b60c1 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via d84233a70dea19b5188700c63c2b1164c97cf8fe (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via e17f270b7acdfc5e6cfd3179a9f48da53a258996 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 7023f610d4aab3f37197e829a3ba07bc4c30a502 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 40d2da09c5d2b8659119da31b2f3d43acef3df6b (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via ae616023855d4e3772faa424fbf9970143a66b63 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 6c6c2664394d9542cf611b7941c0f45cffd1e108 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 7d02020d682018a541b10460b28d6a8d0ef9bcf3 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via bf6560091d2d3cc2c57852d414580643036a1974 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 8ef15df7000bc514b941f04784bccb340f9638b4 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 7815a1531d8dc1c290ed120955eb2f83270b3e99 (commit)
via
54 matches
Mail list logo
