On Friday 17 February 2012, Eric Noulard wrote:
2012/2/16 Brad King brad.k...@kitware.com:
...
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that
2012/2/17 Alexander Neundorf neund...@kde.org:
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 write,
I
2012/2/17 Stephen Kelly steve...@gmail.com:
Hi there,
Also in this thread one of the discussion topics was making CMake default to
creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or
MACOSX_BUNDLE property on the executable target.
2012/2/17 Alexander Neundorf neund...@kde.org:
On Friday 17 February 2012, Eric Noulard wrote:
2012/2/17 Alexander Neundorf neund...@kde.org:
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
On Friday 17 February 2012, Eric Noulard wrote:
...
PS: I start to think in most simple cases CONFIG_TEMPLATE could be
made optional as well if we add another TARGET_EXPORT_FILE option which
indicates the name of export(TARGETS ... FILE ...), using this a proper
config template could be
On Thursday 16 February 2012, Alexander Neundorf wrote:
Hi,
when I use a Find-module to search for a package, I get a nice error
message if the package could not be found.
I collected the various error messages which can be produced in the
different
cases:
* package not found
* package
On Friday 17 February 2012, Rolf Eike Beer wrote:
On Thursday 16 February 2012, Alexander Neundorf wrote:
...
What should be improved:
1.), 2.), 4.) processing should stop if REQUIRED was used
I disagree. Say I want to build $random package. Throw the source
somewhere, run cmake. Now I
Eric Noulard wrote:
2012/2/17 Stephen Kelly
steve...@gmail.com:
Hi there,
Also in this thread one of the discussion topics was making CMake default
to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE
or MACOSX_BUNDLE property on the executable target.
On Friday 17 February 2012, Alexander Neundorf wrote:
...
What should be improved:
...
2.) CMAKE_PREFIX_PATH should be mentioned
1.), 2.) if a version number was used, this should be printed in the error
message
1.) CMAKE_PREFIX_PATH should be mentioned at least.
These three points and a
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 write,
I think I liked the previous version with the fixed
Marcel Loose wrote:
Hi,
On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote:
-- 8 8 8 8 8 8 8 8 8 --
So the suggestion is
a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but
not when
building (I don't know if that's
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
--- a/templates/tests/CMakeLists.txt
+++
Marcel Loose wrote:
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
---
2012/2/17 Stephen Kelly steve...@gmail.com:
Marcel Loose wrote:
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
index
Eric Noulard wrote:
2012/2/17 Stephen Kelly
steve...@gmail.com:
Marcel Loose wrote:
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
On Friday 17 February 2012, Stephen Kelly wrote:
...
The other issue is regarding setting RPATH for the build step and not the
install step, and what syntax should be used for that.
The options are:
a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the build
dir (does
Alexander Neundorf wrote:
On Friday 17 February 2012, Stephen Kelly wrote:
...
The other issue is regarding setting RPATH for the build step and not the
install step, and what syntax should be used for that.
The options are:
a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH
Brad King wrote:
On 2/17/2012 5:44 AM, Stephen Kelly wrote:
I meant 'default' in the sense of
cmTarget::SetPropertyDefault, in the same way that set(CMAKE_AUTOMOC ON)
sets the AUTOMOC property to true by default for all targets that follow.
[snip]
default value of the property *if*
On Friday 17 February 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Friday 17 February 2012, Stephen Kelly wrote:
...
The other issue is regarding setting RPATH for the build step and not
the install step, and what syntax should be used for that.
The options are:
a)
On 2/17/2012 9:27 AM, Stephen Kelly wrote:
Then add SetPropertyDefault in the initialization of EXECUTABLE targets
so that
set(CMAKE_GUI_EXECUTABLE 1)
will change the default for new executable targets in scope of the
variable.
Yes, I had the same idea last night after emailing.
I can
On 2/17/2012 9:31 AM, Alexander Neundorf wrote:
Yes, but this could be done already right now.
We (KDE) could add an option(), which when enabled sets CMAKE_INSTALL_RPATH
empty, and CMAKE_INSTALL_RPATH_USE_LINK_PATH to FALSE. This would be the same
effect.
CMAKE_SKIP_RPATH is intentionally for
On Friday 17 February 2012, Alexander Neundorf wrote:
On Friday 17 February 2012, Brad King wrote:
...
Perhaps we can make the distinction between user and developer right
in the message. When there is no Find module the proper message that
a user sees should talk about ecm_DIR and
On 2/17/2012 11:37 AM, Alexander Neundorf wrote:
developers use Find modules. Consider:
CMake Error at CMakeLists.txt:7 (find_package):
No package configuration file for ecm found by names:
ecmConfig.cmake
ecm-config.cmake
Add the installation prefix of ecm to
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 11:37 AM, Alexander Neundorf wrote:
developers use Find modules. Consider:
CMake Error at CMakeLists.txt:7 (find_package):
No package configuration file for ecm found by names:
ecmConfig.cmake
On Friday 17 February 2012, Alexander Neundorf wrote:
...
But another significant part of the reason is probably that beside
upstreaming a module to cmake, there is no other official way to
distribute Find- modules. So if somebody wrote a libblub, it is a
relatively obvious choice to install
On Wed, Feb 15, 2012 at 9:16 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
- On linux spaces in the path do not work, I get this error:
http://www.cdash.org/CDash/**viewBuildError.php?buildid=**2009436http://www.cdash.org/CDash/viewBuildError.php?buildid=2009436
I think it is a bug in
On 2/17/2012 12:26 PM, Nicolas Desprès wrote:
I think it is a bug in the generator which do not escape the space
properly using the $ character as supported by Ninja.
--
Nicolas Desprès
Will you be able to fix that?
Thanks.
-Bill
--
Powered by www.kitware.com
Visit other Kitware
On 2/17/2012 12:09 PM, Alexander Neundorf wrote:
But another significant part of the reason is probably that beside upstreaming
a module to cmake, there is no other official way to distribute Find-
modules. So if somebody wrote a libblub, it is a relatively obvious choice to
install
On 2/17/2012 12:09 PM, Rolf Eike Beer wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=854e76237ce3e8f03d9cabcad1f8f37e04992ad3
commit 854e76237ce3e8f03d9cabcad1f8f37e04992ad3
Author: Rolf Eike Beere...@sf-mail.de
AuthorDate: Fri Feb 17 18:06:07 2012 +0100
Commit: Rolf Eike
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 12:09 PM, Alexander Neundorf wrote:
But another significant part of the reason is probably that beside
upstreaming a module to cmake, there is no other official way to
distribute Find- modules. So if somebody wrote a libblub, it is a
Brad King wrote:
On 2/17/2012 12:09 PM, Rolf Eike Beer wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=854e76237ce3e8f03d9cabc
ad1f8f37e04992ad3 commit 854e76237ce3e8f03d9cabcad1f8f37e04992ad3
Author: Rolf Eike Beere...@sf-mail.de
AuthorDate: Fri Feb 17 18:06:07 2012 +0100
Eric Noulard wrote:
2012/2/17 Alexander Neundorf neund...@kde.org:
We discussed that too already.
Sorry, I surely missed this part if the discussion,
next time don't bother re-explaining me I'll go and dig the ML.
A digest of the old discussion.
The only non-bloated version of do all the
On 2/17/2012 1:28 PM, Alexander Neundorf wrote:
We can adjust it slightly to avoid the policy warning when FooConfig
is found and Foo_DIR is set:
- search for FindFoo.cmake, use if found
- if not found, check new policy setting
- if not set, enter config mode and emit both the policy
On 2/17/2012 1:31 PM, Rolf Eike Beer wrote:
Does this address
http://www.cmake.org/Bug/view.php?id=12965
Nope, sadly not. But it should make that easier to solve.
Currently we have no official maintainer for the module.
Alex, Eike, do either of you care to take assignment of this issue?
On Friday 17 February 2012, you wrote:
On 2/17/2012 1:31 PM, Rolf Eike Beer wrote:
Does this address
http://www.cmake.org/Bug/view.php?id=12965
Nope, sadly not. But it should make that easier to solve.
Currently we have no official maintainer for the module.
Alex, Eike, do
On 2/17/2012 1:33 PM, Yury G. Kudryashov wrote:
Eric Noulard wrote:
2012/2/17 Alexander Neundorfneund...@kde.org:
We discussed that too already.
Sorry, I surely missed this part if the discussion,
next time don't bother re-explaining me I'll go and dig the ML.
A digest of the old
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 1:28 PM, Alexander Neundorf wrote:
We can adjust it slightly to avoid the policy warning when FooConfig
is found and Foo_DIR is set:
- search for FindFoo.cmake, use if found
- if not found, check new policy setting
-
On Friday 17 February 2012, Alexander Neundorf wrote:
...
Ok :-)
Should I do this by continuing in the FindPackage_ImprovedErrorMessages
branch or create a new branch, branched away from
FindPackage_ImprovedErrorMessages ?
I create a new branch.
Do you want me to add the new keywords ?
On 2/17/2012 1:54 PM, Alexander Neundorf wrote:
Should I do this by continuing in the FindPackage_ImprovedErrorMessages
branch or create a new branch, branched away from
FindPackage_ImprovedErrorMessages ?
The messages will probably be all different with the policy.
Let's start a new one for
On 2/17/2012 2:01 PM, Alexander Neundorf wrote:
Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE
Yes, but I don't think NO_CONFIG_MODE is necessary. NO_MODULE
will become historical. Let's make the new ones consistent with
each other:
Brad King wrote:
On 2/17/2012 1:31 PM, Rolf Eike Beer wrote:
Does this address
http://www.cmake.org/Bug/view.php?id=12965
Nope, sadly not. But it should make that easier to solve.
Currently we have no official maintainer for the module.
Alex, Eike, do either of you care to
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 2:01 PM, Alexander Neundorf wrote:
Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE
Yes, but I don't think NO_CONFIG_MODE is necessary. NO_MODULE
will become historical. Let's make
On 2/17/2012 2:16 PM, Alexander Neundorf wrote:
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 2:01 PM, Alexander Neundorf wrote:
Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE
Yes, but I don't think NO_CONFIG_MODE is necessary.
Brad King wrote:
On 1/20/2012 1:16 PM, Rolf Eike Beer wrote:
What I currently know is:
-if tests run in CMake script mode, they should go in CMakeTests
-if they need to run CMake in configure mode, but don't build anything,
they should go in CMakeOnly
-if they test something from the
2012/2/17 Bill Hoffman bill.hoff...@kitware.com
On 2/17/2012 12:26 PM, Nicolas Desprès wrote:
I think it is a bug in the generator which do not escape the space
properly using the $ character as supported by Ninja.
--
Nicolas Desprès
Will you be able to fix that?
I think yes. It is
I did find out that the ninja generator is not part of the cmake
bootstrap.
Where is the actual cmake repository and branch which contains the ninja
generator
on which we should work?
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Hi,
the CMakeOnly.AllFindModules collects the output of all the Find*.cmake
modules for some weeks now. However it of course can only find what is
installed. There are some modules that find their stuff by querying an
executable for things, like perl and ruby for example. I suspect that these
On 2/17/2012 3:16 PM, Nicolas Desprès wrote:
I think yes. It is just a matter of time. My weekend is already
overloaded. I'll try to do it. If Peter or someone else in the community
comes up with a patch before me everybody would be happy :-)
I'll try to do my best.
I could give it a try if
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 2:16 PM, Alexander Neundorf wrote:
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 2:01 PM, Alexander Neundorf wrote:
Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE
On 2/17/2012 4:01 PM, Alexander Neundorf wrote:
There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the two
keywords, but doesn't change the behaviour yet.
So there wasn't a lot to change in the documentation or tests.
I'll do the modified behaviour together with the policy.
2012/2/17 Nicolas Desprès nicolas.desp...@gmail.com
2012/2/17 Bill Hoffman bill.hoff...@kitware.com
On 2/17/2012 3:16 PM, Nicolas Desprčs wrote:
I think yes. It is just a matter of time. My weekend is already
overloaded. I'll try to do it. If Peter or someone else in the community
comes
On Friday 17 February 2012, Brad King wrote:
On 2/17/2012 4:01 PM, Alexander Neundorf wrote:
There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the
two keywords, but doesn't change the behaviour yet.
So there wasn't a lot to change in the documentation or tests.
I'll do
On 2/17/2012 5:05 PM, Alexander Neundorf wrote:
I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking
backward compatibility of users projects (not cmake) this way.
We can add them and document them in the new version but not mention
them in error messages for now.
53 matches
Mail list logo
