Re: [cmake-developers] Making Config.cmake files easier to write
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 prefix the file refers to all the other pieces (include, etc.) which exist at a fixed location relative to BarConfig.cmake. Right I did not realize that relative position should still be valid. In fact I'm pretty sure you can break this if you mess-up with absolute install destination, but if ones to that there is no point in using this so... It works with absolute install destinations as long as they point to subdirectories of CMAKE_INSTALL_PREFIX. If they point somewhere else, they are really fixed. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
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 think I liked the previous version with the fixed names
(CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
I think the fixed names are better/simpler too. I'm not fond of
CONFIG_HELPER specifically. The information stored in them is
about the *package* that the file is configuring, which is why
I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR
is where the *package* goes, not where the config helper is/goes.
I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
It has documentation and a test.
An example Config.cmake.in file is attached.
I can still change names etc. tomorrow.
The macro is in CMakePackageHelpers.cmake.
Nice piece of work. Should be helpful to many of us.
Some more tuning remarks.
Why not offering more bundled interface to this feature ?
currently you have to:
1) include(CMakePackageConfigHelpers)
2) configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION
${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS
INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
3)
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
VERSION 1.2.3
COMPATIBILITY
SameMajorVersion)
4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
1) is mandatory of course
3) is optional
2) and 4) should be using the same INSTALL_DESTINATION and
DESTINATION in order to be consistent.
I cannot imagine doing 2) or 3) without 4).
So in the end, wouldn't it be simpler (for the user/developer) to have
something like:
include(CMakePackageConfigHelpers)
create_and_install_package_config_files(NAME Foo
CONFIG_TEMPLATE FooConfig.cmake.in
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS
INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
VERSION 1.2.3
VERSION_COMPATIBILITY SameMajorVersion)
This would do the same as 1) + 2) + 3) +4) but...
a) enforces that 2) INSTALL_DESTINATION and 4) DESTINATION are the same
and produce appropriate install rule.
b) enforces that whatever the name of the CONFIG_TEMPLATE you end up with
NAMEConfig.cmake
and
NAMEConfigVersion.cmake
I think this is a good point because you don't have the choice of
the name do you?
c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger
the creation (and install rule) of NAMEConfigVersion.cmake
I can try to write (probably tomorrow) the proposed macro using those
provided by Alex
if you find the idea useful. The proposed macro is not meant replace
the Alex's one but
to offer higher-level [possibly] simpler API.
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 created as well.
PS2: we may need to add an optional COMPONENT option as well if the
generated install rule should
be put in some install component.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making GUI applications by default
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. http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005 By default CMake does not set those properties, which is actually uncommon. Generally in KDE at least, only unit tests and some small utilities are non- gui executables. We'd like to be able to specify with a defaultProperty something like set(CMAKE_CREATE_GUI_EXECUTABLES ON) You probably mean: set_property(GLOBAL PROPERTY CMAKE_CREATE_GUI_EXECUTABLES ON) which would set those target properties to True on the Windows and Mac platforms by default. For unit tests, we could then disable it again. Thoughts/comments? I have [at least] one project which build on Windows where some applications (not test) are not GUI apps. In fact those applications are seldom launched by the user because they are forked by some GUI apps. If this was set by default would my apps still be working as expected? or shall I put NON-GUI properties on them? If this was to be introduced I bet the default value of the property should be OFF (or not SET) for backward compatibility reason. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
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 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 names
(CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
I think the fixed names are better/simpler too. I'm not fond of
CONFIG_HELPER specifically. The information stored in them is
about the *package* that the file is configuring, which is why
I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR
is where the *package* goes, not where the config helper is/goes.
I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
It has documentation and a test.
An example Config.cmake.in file is attached.
I can still change names etc. tomorrow.
The macro is in CMakePackageHelpers.cmake.
Nice piece of work. Should be helpful to many of us.
Some more tuning remarks.
Why not offering more bundled interface to this feature ?
currently you have to:
1) include(CMakePackageConfigHelpers)
2) configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
3) write_basic_package_version_file(
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
VERSION 1.2.3 COMPATIBILITY
SameMajorVersion)
4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
Yes, these are all simple orthogonal functions, which can be described with
one sentence without using and.
1) is mandatory of course
3) is optional
2) and 4) should be using the same INSTALL_DESTINATION and
DESTINATION in order to be consistent.
I cannot imagine doing 2) or 3) without 4).
You are right.
It is a somewhat problematic point that the destinations must match.
So in the end, wouldn't it be simpler (for the user/developer) to have
something like:
include(CMakePackageConfigHelpers)
create_and_install_package_config_files(NAME Foo
CONFIG_TEMPLATE FooConfig.cmake.in
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
VERSION 1.2.3
VERSION_COMPATIBILITY SameMajorVersion)
This would do the same as 1) + 2) + 3) +4) but...
a) enforces that 2) INSTALL_DESTINATION and 4) DESTINATION are the
same and produce appropriate install rule.
This is good on one side, but on the other side I always try not to hide
simple cmake commands.
I mean, every cmake-using developer should know configure_file() and
install(FILES). IMO it is ok if they have to use those functions.
Now for the Config file the issue is that it is somewhat complicated to get
them relocatable, so we need a helper here.
Combining the install() command into this macro hides the install(), i.e. if I
would search the CMakeLists.txt for install command, to find out what is
installed, I might not notice that this
create_and_install_package_config_files() wraps an install() command.
That's why I kept the install() out of the macro, so that for installing
anything there is always an install() command visible.
(this is a not sure we should do this, not a I seriously object to this
idea)
I agree with all this, and like I said my proposal was not about replacing
your set macros but more like offering an extra high-level one.
b) enforces that whatever the name of the CONFIG_TEMPLATE you end up
with NAMEConfig.cmake
and
NAMEConfigVersion.cmake
I think this is a good point because you don't have the choice of
the name do you?
...and the macro should FATAL_ERROR if CONFIG_TEMPLATE doesn't match
*Config.cmake.in or *-config.cmake.in ?
Sounds ok.
c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger the creation (and install rule) of
NAMEConfigVersion.cmake
Maybe. OTOH, is there any reason to install a package without version numbers
?
None I think but we could offer a way to the developer to craft his
own Version file
so if those are not specified this means that the developer is
handling this by himself.
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 created as well.
We discussed that too
Re: [cmake-developers] Making Config.cmake files easier to write
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 created as well. 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. Not sure whether it was here or on kde-buildsystem. ...agree to everything else. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
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 found, but version doesn't match * REQUIRED * without REQUIRED * find_package() with no Find-module present * find_package(NO_MODULE) * find_package() with a wrapper Find-module which does: find_package(ecm QUIET NO_MODULE) fphsa(ecm CONFIG_MODE) Here we go: package not found, REQUIRED: 1.) find_package() with no Find-module present: CMake Error at CMakeLists.txt:4 (find_package): Could not find module Findecm.cmake or a configuration file for package ecm. Adjust CMAKE_MODULE_PATH to find Findecm.cmake or set ecm_DIR to the directory containing a CMake configuration file for ecm. The file will have one of the following names: ecmConfig.cmake ecm-config.cmake * processing continues, but with error 2.) find_package(NO_MODULE): CMake Error at CMakeLists.txt:4 (find_package): Could not find a configuration file for package ecm. Set ecm_DIR to the directory containing a CMake configuration file for ecm. The file will have one of the following names: ecmConfig.cmake ecm-config.cmake * processing continues, but with error 4.) find_package() with no Find-module present, same with NO_MODULE: CMake Error at CMakeLists.txt:4 (find_package): Could not find a configuration file for package ecm that is compatible with requested version 0.0.4. The following configuration files were considered but not accepted: /opt/ecm/share/ecm-0.0.2/cmake/ecm-config.cmake, version: 0.0.2 /opt/ecm/share/ecm-0.0.3/cmake/ecm-config.cmake, version: 0.0.3 * processing continues, but with error 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 see the errors and install the packages that are missing. If processing immediately stops on an unmet dependency I would have to repeat that as long as there are unmet dependencies. If processing continues but gives and error I can install all things at once. 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
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 see the errors and install the packages that are missing. If processing immediately stops on an unmet dependency I would have to repeat that as long as there are unmet dependencies. If processing continues but gives and error I can install all things at once. Well, at least it is inconsistent with the behaviour of all Find-modules. They all stop with FATAL_ERROR if a REQUIRED package was not found. The documentation page says: The REQUIRED option stops processing with an error message if the package cannot be found. I interpret this as stops processing immediately. This is what find_package_handle_standard_args() does. If this is not the intended meaning, then all the Find-modules (mostly FindPackageHandleStandardArgs) should be changed to use SEND_ERROR instead of FATAL_ERROR. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making GUI applications by default
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. http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005 By default CMake does not set those properties, which is actually uncommon. Generally in KDE at least, only unit tests and some small utilities are non- gui executables. We'd like to be able to specify with a defaultProperty something like set(CMAKE_CREATE_GUI_EXECUTABLES ON) You probably mean: set_property(GLOBAL PROPERTY CMAKE_CREATE_GUI_EXECUTABLES ON) Nope, I meant the one I wrote. It'a similar to, eg, set(CMAKE_AUTOMOC ON) and many others. which would set those target properties to True on the Windows and Mac platforms by default. For unit tests, we could then disable it again. Thoughts/comments? I have [at least] one project which build on Windows where some applications (not test) are not GUI apps. In fact those applications are seldom launched by the user because they are forked by some GUI apps. If this was set by default would my apps still be working as expected? If you change nothing they will continue to work as expected. If you add set(CMAKE_CREATE_GUI_EXECUTABLES ON) then you would have to use set_target_property(foo WIN32_EXECUTABLE 0) on the non-gui executable in the project. Note that I think I caused confusion for you when I wrote 'by default'. I didn't actually mean that CMake should change its default behaviour in a source incompatible way. 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. or shall I put NON-GUI properties on them? If this was to be introduced I bet the default value of the property should be OFF (or not SET) for backward compatibility reason. Of course. I don't intend to change the default behaviour of CMake, just the default value of the property *if* set(CMAKE_CREATE_GUI_EXECUTABLES) is ON. Thanks, Steve. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default
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 small bug fix (error message was not printed at all for an invalid CONFIGS name) are now in the FindPackage_ImprovedErrorMessages branch and merged into next. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
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 names (CONFIG_HELPER) better. I think it was easier to do, a simple scheme. I think the fixed names are better/simpler too. I'm not fond of CONFIG_HELPER specifically. The information stored in them is about the *package* that the file is configuring, which is why I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR is where the *package* goes, not where the config helper is/goes. It's also the same as the package version file input/output variable names. I looked a bit around cmFindPackage. It has a parameter CONFIGS, it has a Config mode and the documentation and error messages use configuration file. 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). Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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 easy in CMake), or alternatively
provide
another CMAKE_ variable to do that.
b) Implement something like:
set_property(TARGET foo APPEND PROPERTY TEST_ENVIRONMENT foo=bar)
Possibly both a) and b).
Thoughts/comments?
b) is IMO definitely a missing feature.
(but even with that, we (KDE) would have to keep a macro, because we
can't
expect that all developers know how to set this properly for all
platforms.
...or, since it is a target property, this could be also intialized
from a
CMAKE_TEST_ENVIRONMENT cmake variable).
Maybe I'm missing the point but there is a property ENVIRONMENT for
tests:
http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:ENVIRONMENT
That indeed looks like what was discussed in one of the links I posted.
However I tried it out and it didn't work for me (with CMAKE_SKIP_RPATH):
stephen@hal:~/dev/build/qt/grantlee$ LD_LIBRARY_PATH=$PWD/templates/lib
./templates/tests/testsafestring_exec
* Start testing of TestSafeString *
Config: Using QTest library 4.7.4, Qt 4.7.4
PASS : TestSafeString::initTestCase()
PASS : TestSafeString::testCombining()
PASS : TestSafeString::testAppending()
PASS : TestSafeString::testChopping()
PASS : TestSafeString::testReplacing()
PASS : TestSafeString::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped
* Finished testing of TestSafeString *
Qt( ) KDE ( )
stephen@hal:~/dev/build/qt/grantlee$ ctest -V .
UpdateCTestConfiguration from
:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
Parse Config file:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
UpdateCTestConfiguration from
:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
Parse Config file:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
Test project /home/stephen/dev/build/qt/grantlee
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: testsafestring
1: Test command:
/home/stephen/dev/build/qt/grantlee/templates/tests/testsafestring_exec
1: Test timeout computed to be: 1500
1: /home/stephen/dev/build/qt/grantlee/templates/tests/testsafestring_exec:
error while loading shared libraries: libgrantlee_core.so.0: cannot open
shared object file: No such file or directory
1/11 Test #1: testsafestring ...***Failed0.00 sec
Qt( ) KDE ( )
stephen@hal:~/dev/src/grantlee{master}$ git diff
diff --git a/templates/tests/CMakeLists.txt b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
--- a/templates/tests/CMakeLists.txt
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
)
add_test(${_testname} ${_testname}_exec )
+set_property(TEST ${testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
Do you see anything wrong there?
Thanks,
Steve.
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
)
add_test(${_testname} ${_testname}_exec )
+set_property(TEST ${testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
Do you see anything wrong there?
You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
testname as well.
Thanks,
Steve.
Cheers,
Marcel.
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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
--- a/templates/tests/CMakeLists.txt
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
)
add_test(${_testname} ${_testname}_exec )
+set_property(TEST ${testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
Do you see anything wrong there?
You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
testname as well.
D'Oh! You're right. I typo'd there. It works with my system Qt if I fix the
typo.
However, it doesn't solve the whole problem for me. Mostly I use a Qt in a
non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many Qts
and a script to change my environment)
I tried changing it to
set_property(TEST ${_testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib)
ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt. It
found my system Qt (4.7) instead of my environment Qt (4.8) which has new
methods and so I get symbol lookup errors.
Is that something relevant for others that we should care about? Or is my
setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from my
environment is not carried over?
Thanks,
Steve.
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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 d2e37d2..ad471c7 100644
--- a/templates/tests/CMakeLists.txt
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
)
add_test(${_testname} ${_testname}_exec )
+ set_property(TEST ${testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
Do you see anything wrong there?
You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
testname as well.
D'Oh! You're right. I typo'd there. It works with my system Qt if I fix the
typo.
However, it doesn't solve the whole problem for me. Mostly I use a Qt in a
non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many Qts
and a script to change my environment)
I tried changing it to
set_property(TEST ${_testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib)
ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt.
I'm not sure it'll append using this shell-like syntax, which suppose
shell-like evaluation for $LD_LIBRARY_PATH.
Could you try
LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}:${CMAKE_BINARY_DIR}/templates/lib
instead, which uses the CMake variable syntax to access environment.
Is that something relevant for others that we should care about? Or is my
setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from my
environment is not carried over?
Does you initial environment export LD_LIBRARY_PATH or not (simple set) ?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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
b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
--- a/templates/tests/CMakeLists.txt
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
)
add_test(${_testname} ${_testname}_exec )
+set_property(TEST ${testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
Do you see anything wrong there?
You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
testname as well.
D'Oh! You're right. I typo'd there. It works with my system Qt if I fix
the typo.
However, it doesn't solve the whole problem for me. Mostly I use a Qt in
a non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many
Qts and a script to change my environment)
I tried changing it to
set_property(TEST ${_testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib)
ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt.
I'm not sure it'll append using this shell-like syntax, which suppose
shell-like evaluation for $LD_LIBRARY_PATH.
Could you try
LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}:${CMAKE_BINARY_DIR}/templates/lib
instead, which uses the CMake variable syntax to access environment.
Yes, that works fine as expected, thanks!
Is that something relevant for others that we should care about? Or is my
setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from
my environment is not carried over?
Does you initial environment export LD_LIBRARY_PATH or not (simple set) ?
It is exported.
So that resolves one of the two issues I posted about.
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 this need a policy)
b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the
installation RPATH, but do use it for the build step. (Fits with existing
CMAKE_SKIP_BUILD_RPATH)
c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if set
to false. (This probably would need a policy)
My choice is b), but I don't know if there are good reasons for the others.
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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 this need a policy) b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the installation RPATH, but do use it for the build step. (Fits with existing CMAKE_SKIP_BUILD_RPATH) c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if set to false. (This probably would need a policy) My choice is b), but I don't know if there are good reasons for the others. I'm not sure this would help a lot. Some people (distro packagers) disable RPATH by setting CMAKE_SKIP_RPATH to TRUE. CMAKE_SKIP_RPATH is the big switch which overrides all others. So if this is used, we would still have no RPATH in the build tree. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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 in the build dir (does this need a policy) b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the installation RPATH, but do use it for the build step. (Fits with existing CMAKE_SKIP_BUILD_RPATH) c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if set to false. (This probably would need a policy) My choice is b), but I don't know if there are good reasons for the others. I'm not sure this would help a lot. Some people (distro packagers) disable RPATH by setting CMAKE_SKIP_RPATH to TRUE. CMAKE_SKIP_RPATH is the big switch which overrides all others. So if this is used, we would still have no RPATH in the build tree. Are you saying this is a chicken-egg problem? If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and CMAKE_SKIP_RPATH is not, distros will learn that they can run unit tests if they build their packages with the former instead of the latter. From my point of view though, the ENVIRONMENT property manipulation solves enough of the problem already. It makes 'make test' work. What it doesn't fix is running a unit test executable directly without setting the environment manually or running make install. I don't see why that should be expected to work though if the developer disables the RPATH stuff. It also doesn't work currently (without wrapper scripts), so nothing is really lost. However, adding CMAKE_SKIP_INSTALL_RPATH would make that work even if a developer wanted to disable RPATH, so maybe it's a nice thing to do. Thanks, Steve. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making GUI applications by default
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* set(CMAKE_CREATE_GUI_EXECUTABLES) is ON. Instead of a special behavior for WIN32_EXECUTABLE and MACOSX_BUNDLE property defaults, consider creating a new property that generalizes the concept, such as GUI_EXECUTABLE. Teach the code and update the documentation to specify that the property implies WIN32_EXECUTABLE and MACOSX_BUNDLE on the respective platforms. 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 implement that. Thanks, Steve. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the build dir (does this need a policy) b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the installation RPATH, but do use it for the build step. (Fits with existing CMAKE_SKIP_BUILD_RPATH) c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if set to false. (This probably would need a policy) My choice is b), but I don't know if there are good reasons for the others. I'm not sure this would help a lot. Some people (distro packagers) disable RPATH by setting CMAKE_SKIP_RPATH to TRUE. CMAKE_SKIP_RPATH is the big switch which overrides all others. So if this is used, we would still have no RPATH in the build tree. Are you saying this is a chicken-egg problem? If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and CMAKE_SKIP_RPATH is not, distros will learn that they can run unit tests if they build their packages with the former instead of the latter. From my point of view though, the ENVIRONMENT property manipulation solves enough of the problem already. It makes 'make test' work. What it doesn't fix is running a unit test executable directly without setting the environment manually or running make install. I don't see why that should be expected to work though if the developer disables the RPATH stuff. It also doesn't work currently (without wrapper scripts), so nothing is really lost. However, adding CMAKE_SKIP_INSTALL_RPATH would make that work even if a developer wanted to disable RPATH, so maybe it's a nice thing to do. 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 people who just want to disable RPATH no matter what the project does. ...maybe we (KDE) could do: if(CMAKE_SKIP_RPATH) set(CMAKE_SKIP_RPATH FALSE) set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE) set(CMAKE_INSTALL_RPATH ) endif() ... I didn't say that loud, did I ? ;-) Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making GUI applications by default
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 implement that. Great. On second thought I wonder if a better name for the property is EXECUTABLE_GUI since that uses the prefix EXECUTABLE_ which can be re-used later for other properties that are specific to executable targets. Then one could write set(CMAKE_EXECUTABLE_GUI 1) for the variable version and CMAKE_EXECUTABLE_ is the prefix for settings related to executables. Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
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 people who just want to disable RPATH no matter what the project does. ...maybe we (KDE) could do: if(CMAKE_SKIP_RPATH) set(CMAKE_SKIP_RPATH FALSE) set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE) set(CMAKE_INSTALL_RPATH ) endif() As I said in parallel to your response I'd prefer that distros use a hammer like CMAKE_SKIP_INSTALL_RPATH so they do not have to depend on the project supporting it with code like the above. I'd like to discourage them from using CMAKE_SKIP_RPATH because it is a pain for testing. Of course your approach doesn't depend on any new CMake changes so you can use it right now to get started. -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 CMAKE_PREFIX_PATH only.
This should be the focus. We can then add an extra note to help
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 CMAKE_PREFIX_PATH or
set ecm_DIR to a directory containing one of the above files.
(If you are a developer expecting this find_package to load a
Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)
I'm still not convinced.
Just today I found this commit from last October in kdelibs:
http://quickgit.kde.org/index.php?p=kdelibs.gita=commitdiffh=ca501aa9f4c1
e7adcd42accbd53538502ba50ce3hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655
Commit message: on win32 we need access to the installed cmake modules dir
--- a/cmake/modules/FindKDE4Internal.cmake
+++ b/cmake/modules/FindKDE4Internal.cmake
@@ -736,6 +736,7 @@ endif(${CMAKE_MAJOR_VERSION}.${CMAKE_MIN
option(KDE4_ENABLE_FPIE Enable platform supports PIE linking)
if (WIN32)
+ list(APPEND CMAKE_MODULE_PATH
${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules)
find_package(KDEWin REQUIRED)
option(KDE4_ENABLE_UAC_MANIFEST add manifest to make... OFF)
if (KDE4_ENABLE_UAC_MANIFEST)
This looks really wrong (I mean this directory is not guaranteed to exist
at all at cmake time, so it can't help finding a module file), and it was
committed by a developer who is using cmake now already since 2006 at
least.
If I would build this, I would get exactly to case 1) - neither Find-module
nor config-file found.
As user I should assume that there should be a config file, and I should
install the package or set CMAKE_PREFIX_PATH. But this wouldn't help,
because actually the Find-module is missing, because in some way the
buildsystem expects something wrong.
So when I (as user) would assume the package is not installed because the
config has not been found, I would be wrong, but I couldn't see this from
the code.
If config-file searching would have to be enabled, I would know from the
error message (which would then say Find-module not found) that the
buildsystem is broken, and not some package is missing or
CMAKE_PREFIX_PATH is not set.
IOW: it's a quite common error to install a FindFoo.cmake as part of the
package Foo into the prefix where foo is installed.
So if cmake knows that really the Find-module should have been found, it can
produce a very clear error message that the missing Find-module must be part
of the project itself or provided by another previously found package, and
that the buildsystem is broken.
Alex
--
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:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 CMAKE_PREFIX_PATH or set ecm_DIR to a directory containing one of the above files. (If you are a developer expecting this find_package to load a Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.) I'm still not convinced. Convinced of what? I'm suggesting alternative wording for a change you just committed yourself. Whether to introduce the policy is another decision which should be resolved before any changes for this end up in master. IOW: it's a quite common error to install a FindFoo.cmake as part of the package Foo into the prefix where foo is installed. Any suggestion how to correct this misconception? There is no place in any of our documentation or tutorials on the wiki that suggests it. So if cmake knows that really the Find-module should have been found, it can produce a very clear error message that the missing Find-module must be part of the project itself or provided by another previously found package, and that the buildsystem is broken. This discussion relates to the introduction of the policy you proposed. Please comment on my question from yesterday: On 2/16/2012 11:57 AM, Brad King wrote: So your proposal when no extra find_package mode arg is given is: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path ? Separately the CONFIG and MODULE explicit mode args can be given to be alternative to NO_MODULE. -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 ecm-config.cmake Add the installation prefix of ecm to CMAKE_PREFIX_PATH or set ecm_DIR to a directory containing one of the above files. (If you are a developer expecting this find_package to load a Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.) I'm still not convinced. Convinced of what? I'm suggesting alternative wording for a change you just committed yourself. Not convinced that splitting the error message this way is appropriate, and also not convinced that it is good that config-files are searched also without NO_MODULE. Whether to introduce the policy is another decision which should be resolved before any changes for this end up in master. IOW: it's a quite common error to install a FindFoo.cmake as part of the package Foo into the prefix where foo is installed. Any suggestion how to correct this misconception? There is no place in any of our documentation or tutorials on the wiki that suggests it. I may be part of the problem. We install a lot of Find-modules with kdelibs, so developers got the impression that this is a good thing to do, so they do this now too for their libraries. 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 FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) (But what I did never do is to install FindKDE4.cmake as part of kdelibs, FindKDE4.cmake comes with cmake, so that is fine. And once you found kdelibs, it is ok to use the modules installed by kdelibs.) By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Did not find FindFoo.cmake. FindFoo.cmake must either be part of the project itself, in this case adjust CMAKE_MODULE_PATH so that it points to the correct location inside your source tree. Or it must be installed by a package which has already been found via find_package(). In this case make sure that this package has indeed been found and adjust CMAKE_MODULE_PATH to contain the location where that package has installed FindFoo.cmake. This must be a variable provided by that package. If you are developer of the current project, go fix your buildsystem ! If you are only building this project, tell the developers to fix their buildsystem ! Well, something like this. ;-) So if cmake knows that really the Find-module should have been found, it can produce a very clear error message that the missing Find-module must be part of the project itself or provided by another previously found package, and that the buildsystem is broken. This discussion relates to the introduction of the policy you proposed. Please comment on my question from yesterday: On 2/16/2012 11:57 AM, Brad King wrote: So your proposal when no extra find_package mode arg is given is: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path ? Separately the CONFIG and MODULE explicit mode args can be given to be alternative to NO_MODULE. Yes, exactly. I think I didn't answer explicitely because it seemed clear to me that this is exactly what I meant :-) Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. I did not make that up, this email from Pau on the buildsystem list just arrived after I sent this email here: http://lists.kde.org/?l=kde-buildsystemm=132949736429566w=2 Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja spaces in the path do not work on linux
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 the generator which do not escape the space properly using the $ character as supported by Ninja. -- Nicolas Desprès -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja spaces in the path do not work on linux
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 open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. If the Blub project is built with CMake then there should be no FindBlub for it at all. It should just install BlubConfig.cmake and be done. Perhaps your work to make the files easier to write will help with that. The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) I'll have to think about how to deal with that. By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Adding the explicit MODULE mode keyword could help with that. - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Yes, exactly. 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 warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path One problem with the policy is that it favors module mode as the normal case and makes config mode look like something special. That will not help with the perception that the latter is preferred. -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake improve-findruby topic
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 Beere...@sf-mail.de CommitDate: Fri Feb 17 18:06:07 2012 +0100 FindRuby: clean up querying variables from Ruby Newer Ruby versions (from 1.9 onward) seem to warn if you query Config::CONFIG and print a warning to use RbConfig instead. RbConfig seems to also work in older versions, at least in 1.8. Use a macro to query RbConfig first and only if that doesn't give anything fall back to Config. Does this address http://www.cmake.org/Bug/view.php?id=12965 ? Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. If the Blub project is built with CMake then there should be no FindBlub for it at all. It should just install BlubConfig.cmake and be done. Perhaps your work to make the files easier to write will help with that. Yes, but people do that all the time. I think I saw this for more or less every library which was written in KDE, and whenever I saw it I explained that distributing the Find-module together with the library doesn't make sense. I'm sure I didn't get all cases. The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) I'll have to think about how to deal with that. By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Adding the explicit MODULE mode keyword could help with that. - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Yes, exactly. 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 warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Just to make sure I understand: behave as described intially, but don't warn if the config file has been found via Foo_DIR. Right ? Ok with me. One problem with the policy is that it favors module mode as the normal case and makes config mode look like something special. That will not help with the perception that the latter is preferred. I actually prefer to have a simple 3 line wrapper Find-module within the project: FindFoo.cmake: find_package(Foo NO_MODULE) fphsa(Foo CONFIG_MODE) set_package_feature(Foo PROPERTIES PURPOSE Enables something in this app TYPE RECOMMENDED URL http://www.foo.org ) so people get a nice short result line during the cmake run and an informative summary at the end of the cmake run via FeatureSummary.cmake Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake improve-findruby topic
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 Commit: Rolf Eike Beere...@sf-mail.de CommitDate: Fri Feb 17 18:06:07 2012 +0100 FindRuby: clean up querying variables from Ruby Newer Ruby versions (from 1.9 onward) seem to warn if you query Config::CONFIG and print a warning to use RbConfig instead. RbConfig seems to also work in older versions, at least in 1.8. Use a macro to query RbConfig first and only if that doesn't give anything fall back to Config. Does this address http://www.cmake.org/Bug/view.php?id=12965 ? Nope, sadly not. But it should make that easier to solve. I wonder what does ruby output on Windows? Likely backslash separated paths, in which case most of those things would also need an additional file(TO_CMAKE_PATH). Eike -- signature.asc Description: This is a digitally signed message part. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
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 cmake-config magic command I see is write_basic_config_file_for_export(MyExport). This would require some changes on C++ side (i.e., make it possible to query MyExport DESTINTATION, NAMESPACE, list of targets etc.). And this will work only for simple cases (e.g., a few libraries/executables with simple version logic). -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Just to make sure I understand: behave as described intially, but don't warn if the config file has been found via Foo_DIR. Right ? Ok with me. Yes. That will avoid unnecessary policy warnings when things work. Please push a proposed implementation to the stage for review. The documentation of the policy will have a lot of history to explain this. Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake improve-findruby topic
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? Otherwise I'll update the issue with a link to the module maintainer page asking for help. Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake improve-findruby topic
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 either of you care to take assignment of this issue? Otherwise I'll update the issue with a link to the module maintainer page asking for help. In general yes, but it's not on my priority list for 2.8.8. So, it would be nice if somebody else could take care of it. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] making exports first-class (was: Making Config.cmake files easier to write)
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 discussion. The only non-bloated version of do all the cmake-config magic command I see is write_basic_config_file_for_export(MyExport). This would require some changes on C++ side (i.e., make it possible to query MyExport DESTINTATION, NAMESPACE, list of targets etc.). And this will work only for simple cases (e.g., a few libraries/executables with simple version logic). If anyone is interested in working on something like this the C++ changes you mention would need to make exports recorded by either export() or install(EXPORT) into first-class objects. A major missing feature from them right now is having multiple logical exports with dependencies. Currently an export must include the transitive closure of its own dependencies. If instead they were first class objects in CMake then then the dependencies of one export could be satisfied by an export-level dependency on another export. Note that this is not directly tied to package configuration file generation. Exports correspond to *target* files that can be loaded by package config files to import the targets provided by an export into another project. I suppose extra properties could be configured on the exports to generate simple package configuration files but as you say it would only work for simple cases. -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Just to make sure I understand: behave as described intially, but don't warn if the config file has been found via Foo_DIR. Right ? Ok with me. Yes. That will avoid unnecessary policy warnings when things work. Please push a proposed implementation to the stage for review. The documentation of the policy will have a lot of history to explain this. Ok :-) Should I do this by continuing in the FindPackage_ImprovedErrorMessages branch or create a new branch, branched away from FindPackage_ImprovedErrorMessages ? Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 ? NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
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 this change and revert the current branch to avoid conflicts. Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. Then the policy can be added on top of it as a new topic. Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake improve-findruby topic
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 take assignment of this issue? Otherwise I'll update the issue with a link to the module maintainer page asking for help. I have no idea of Ruby. I just saw the warnings and fixed them. Eike -- signature.asc Description: This is a digitally signed message part. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 the new ones consistent with each other: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, which has IMO only uncontroversial fixes to the error messages and a small bugfix. Ok ? (since I merged this already into next, and I have never undone such a merge yet) Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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. NO_MODULE will become historical. Let's make the new ones consistent with each other: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, which has IMO only uncontroversial fixes to the error messages and a small bugfix. Ok ? (since I merged this already into next, and I have never undone such a merge yet) Okay. The messages will be tweaked again by the new modes though. -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tests directory layout
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 Modules directory, but do not belong to one of the previous 2 cases, they should go in Modules Correct? Anything else? That covers what little organization we have now ;) Where should such a list go? Tests/README? Wiki? In a README please, for locality of reference. Pushed as commit 378f2291593c5b1d7d9fcd03029b931ce674a3d2 to next. Eike -- signature.asc Description: This is a digitally signed message part. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja spaces in the path do not work on linux
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 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. Cheers, -Nico -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja broken on windows?
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 http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Additional software on a Windows build machine
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 programs will output a native path, i.e. can screw up things severely on Windows. Therefore I would like to see if one of the Kitware build machines could get a bunch of additional stuff installed to give the findmodules something to work on. Currently my main interest would be perl (see e.g. http://www.activestate.com/activeperl/) and ruby (http://rubyforge.org/projects/rubyinstaller/). The reason is simply that I have touched those modules recently and would like to see if they are properly working. Any other stuff you may find suitable (python, lua, whatever libraries) will certainly not hurt either. Thanks, Eike signature.asc Description: This is a digitally signed message part. -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja spaces in the path do not work on linux
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 you pointed me to the right spot in the code... -Bill -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 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: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, which has IMO only uncontroversial fixes to the error messages and a small bugfix. Ok ? (since I merged this already into next, and I have never undone such a merge yet) Okay. The messages will be tweaked again by the new modes though. 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. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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. Looks good. Thanks, -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja spaces in the path do not work on linux
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 up with a patch before me everybody would be happy :-) I'll try to do my best. I could give it a try if you pointed me to the right spot in the code... I think the first place to look at is cmGlobalNinjaGenerator.cxx. There are a bunch of class methods there that are used to write the statements in the .ninja files. Look at WriteBuild() in particular. Many others are convenient methods based on this one. So the escaping logic should happen there. build statements in ninja are where most of the path are written. Some problem may arise from WriteRule() since the path to the command is written by it. Also there are: static std::string EncodeIdent(const std::string ident, std::ostream vars); static std::string EncodeLiteral(const std::string lit); which I don't really know since I haven't written them and they are not documented. Peter did. But their name are pretty explicit and their code trivial. I think we should add an EncodePath() method to follow the same logic and use it in WriteBuild() and WriteRule(). In WriteBuild(), arguments like ouputs, explictDeps, implicitDeps, orderOnlyDeps must be encoded. The tricky part would be that some part of the value of the variables arguments (which is a hash_map) must be encoded because they may be a white space sparated list of word which may contains some paths... Just to be clearer, outputs, explicitDeps, implicitDeps and orderOnlyDeps are all a list of paths (types are declared in cmNinjaTypes.h) so each item of the list must be encoded. A build statements look like this (using the argument name of WriteBuild): comment build outputs: rule explicitDeps | implicitDeps || orderOnlyDeps variables For exemple look at this part of the build.ninja file generated for cmake: build Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o: CXX_COMPILER ../Tests/CMakeLib/testXMLParser.cxx || Source/libCMakeLib.a DEFINES = -DLIBARCHIVE_STATIC FLAGS = -Wall -g -IUtilities -I../Utilities -ITests/CMakeLib -ISource -I../Source or this one: # Link the executable Tests/CMakeLib/CMakeLibTests build Tests/CMakeLib/CMakeLibTests: CXX_EXECUTABLE_LINKER Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/CMakeLibTests.cxx.o Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testGeneratedFileStream.cxx.o Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testSystemTools.cxx.o Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testUTF8.cxx.o Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLSafe.cxx.o | Source/libCMakeLib.a Source/kwsys/libcmsys.a /usr/lib/libexpat.so Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib/libz.so Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a /usr/lib/libcurl.so FLAGS = -Wall -fPIC LINK_LIBRARIES = -rdynamic Source/libCMakeLib.a Source/kwsys/libcmsys.a -ldl -lexpat Utilities/cmlibarchive/libarchive/libcmlibarchive.a -lz Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a -lcurl POST_BUILD = : PRE_LINK = : In this case I think the encoding should happen before the call to WriteBuild when the variables argument is built because WriteBuild would not have enough information to figure out which part of the variable value is a path or not, specially for things like: -I../Utilities Hope this helps, Cheers, -Nico -- Nicolas Desprès -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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 the modified behaviour together with the policy. Looks good. I'm just implementing the warnings There is a problem with the new keywords. If I make the warning ... use the CONFIG_MODE keyword ... and the developer does this then, then his project will not work anymore with older cmake versions, because they don't know CONFIG_MODE. If the warning says instead ... use the NO_MODULE keyword ... then the project will still work with old and new cmake versions correctly. I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking backward compatibility of users projects (not cmake) this way. Alex -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package error wording
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. -Brad -- 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: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
