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
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
2012/2/16 paspa...@noos.fr: Hello, I am trying to use CMake with codeblocks on windows, I created a simple project in the folder pCMake when I use the CMake interface I got the message: You mean graphical interface where you select the generator from a list? CMake Error: CMake was unable to find a build program corresponding to MinGW Makefiles. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. and following the tutorial from florian-goujeon (CMake,CodeBlock), it's advise to execute a cmake --help from a console in the project folder in order to get the generator list codeblocks -MinGW Makefiles is listed but when I execute cMake . -GCodeBlocks -MinGW Makefiles I get also the following message CMake Error:could not create names generator CodeBlocks -MinGW Makefiles There must be a typo in the generator name you used, something like a missing space after the dash '-' or something similar. I installed codeblocks with the windows installer with gcc compiler and cmake with the windows installer I don't know what to do, any suggestions will be very helpful From your first error message CMake was unable to find a build program corresponding to MinGW Makefiles. CMAKE_MAKE_PROGRAM is not set. I would say that CMake is not finding mingw make program because it is not in your PATH. Did you add mingw tools to your path after installing Code::Blocks? I don't remember whether if Code::Blocks does that by itself or not. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] External projects and make clean
Hi, I use external projects e.g. to build BOOST for my own project. In that case I want to prevent the project to be system or version dependent. So I build my dependencies successful with external project (and its great), but if use make clean it will clean all stuff and I have to rebuild the external projects again (take some time with BOOST). Is there a solution to prevent an external project from cleaning when I call 'make clean'? Kind regards Oliver Boesche -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem when globbing files and using that OUTPUT variable between ADD_CUSTOM_COMMAND commands
Hi,i have several ADD_CUSTOM_COMMAND commands with a specified target (let's say TARGET1).Between those commands I need to collect files and want to use those collected files in the next ADD_CUSTOM_COMMAND.How can i do that, because the following doesn't work as expected.ADD_CUSTOM_COMMAND(TARGET TARGET1 COMMAND SAMPLE_COMMAND ARGS ARGUMENTS WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY} COMMENT "Doing some stuff" VERBATIM)# HERE I NEED A CUSTOM COMMAND where the CUSTOM_FILES variable can be used in the next ADD_CUSTOM_COMMANDADD_CUSTOM_COMMAND(OUTPUT CUSTOM_FILES
COMMAND /usr/bin/find ARGS ${CUSTOM_PATH} -type f
COMMENT "Find files"
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ${CUSTOM_FILES}
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT "Doing some stuff"
VERBATIM)ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT "Doing some stuff"
VERBATIM)Thanks in advanceBest RegardsNoRuleu--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
Hello Eric,thank you for your suggestions and supportI am going to try to detail more what I did:- Install CMake on Program Files/CMake 2.8/bin- Install CodeBlocks with its windows installer at the same time he asks if we want the gcc compiler I said okand he installed MinGW in Program Files/CodeBlocks/MinGW- as you suggested he didn't set the path variable so now the path variable are:C:\Program Files\CMake 2.8\bin;C:\Program Files\CodeBlocks\MinGW;- I created a codeblock printhello project named pCMakethen at this step I didn't know what to do exactly:First Attempt:I put a CMakeLists.txt file in the codeblocks "Others" folders with the file containing:cmake_minimum_required(2.8)project(pCMake)add_executable(pCMake main.cpp)and in the Project Properties/Project Settings : I set :Makefile:CMakeLists and check "This is a custom MakeFile"I run a build and get the Result:Running command: make.exe -f CMakeLists DebugExecution of 'make.exe -f CMakeLists Debug' in 'C:\pCMake' failed.Second Attempt:use CMake cmake-gui interface where is the source code:C:\pCMakewhere to buid the binaries:C:\pCMakeI push the button: Generatespecify the generator for this project:select in the combo :CodeBlocks-MinGW MakeFilescheck Use Default native compilersresult:CMake Error at CMakeLists.txt:1 (cmake_minimum_required): cmake_minimum_required called with unknown argument "2.8". CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.thanks again if you can suggest somethingpascal Message d'origine De : "Eric Noulard" eric.noul...@gmail.com À : paspa...@noos.fr Objet : Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles Date : 17/02/2012 09:47:43 CET Copie à : cmake@cmake.org 2012/2/16 paspa...@noos.fr: Hello, I am trying to use CMake with codeblocks on windows, I created a simple project in the folder pCMake when I use the CMake interface I got the message: You mean "graphical interface" where you select the generator from a list? CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. and following the tutorial from florian-goujeon (CMake,CodeBlock), it's advise to execute a cmake --help from a console in the project folder in order to get the generator list codeblocks -MinGW Makefiles is listed but when I execute cMake . -G"CodeBlocks -MinGW Makefiles" I get also the following message CMake Error:could not create names generator CodeBlocks -MinGW Makefiles There must be a typo in the generator name you used, something like a missing space after the dash '-' or something similar. I installed codeblocks with the windows installer with gcc compiler and cmake with the windows installer I don't know what to do, any suggestions will be very helpful From your first error message CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. I would say that CMake is not finding mingw make program because it is not in your PATH. Did you add mingw tools to your path after installing Code::Blocks? I don't remember whether if Code::Blocks does that by itself or not. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
2012/2/17 paspa...@noos.fr: Hello Eric, thank you for your suggestions and support I am going to try to detail more what I did: - Install CMake on Program Files/CMake 2.8/bin - Install CodeBlocks with its windows installer at the same time he asks if we want the gcc compiler I said ok and he installed MinGW in Program Files/CodeBlocks/MinGW - as you suggested he didn't set the path variable so now the path variable are: C:\Program Files\CMake 2.8\bin;C:\Program Files\CodeBlocks\MinGW; - I created a codeblock printhello project named pCMake then at this step I didn't know what to do exactly: First Attempt: I put a CMakeLists.txt file in the codeblocks Others folders with the file containing: cmake_minimum_required(2.8) project(pCMake) add_executable(pCMake main.cpp) and in the Project Properties/Project Settings : I set : Makefile:CMakeLists and check This is a custom MakeFile OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txt May be you could read the beginning of thoses documents: http://www.cmake.org/cmake/help/cmake_tutorial.html https://github.com/TheErk/CMake-tutorial/raw/master/CMake-tutorial-8feb2012.pdf in order to have a better idea of the CMake workflow. Second Attempt: use CMake cmake-gui interface where is the source code:C:\pCMake where to buid the binaries:C:\pCMake It is better habit to have separate directories for sources and binaries. see: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees I push the button: Generate specify the generator for this project: select in the combo :CodeBlocks-MinGW MakeFiles check Use Default native compilers result: CMake Error at CMakeLists.txt:1 (cmake_minimum_required): cmake_minimum_required called with unknown argument 2.8 you have a syntax error in your CMakeLists.txt you should write cmake_minimum_required(VERSION 2.8) read on the documentation: http://www.cmake.org/cmake/help/documentation.html CMake Error: CMake was unable to find a build program corresponding to MinGW Makefiles. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. find make.exe program in your Code::Blocks install and add the path to it to your PATH. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem when globbing files and using that OUTPUT variable between ADD_CUSTOM_COMMAND commands
2012/2/17 NoRulez noru...@me.com:
Hi,
i have several ADD_CUSTOM_COMMAND commands with a specified target (let's
say TARGET1).
Between those commands I need to collect files and want to use those
collected files in the next ADD_CUSTOM_COMMAND.
How can i do that, because the following doesn't work as expected.
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
may be you could do:
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
COMMAND ${CMAKE_COMMAND} -DOutFile=fl.cmake -P
collectFiles.cmake
COMMAND ${CMAKE_COMMAND} -DInFile=fl.cmake -P
doPostProcessing.cmake
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
the collectFiles step will do whatever you want and create the fl.cmake
file
which will be loaded by the second doPostProcessing in order to get
access to list of file in a pre-defined CMake var.
You can split this in separate add_custom_command but I don't see the need
in your example.
# HERE I NEED A CUSTOM COMMAND where the CUSTOM_FILES variable can be used
in the next ADD_CUSTOM_COMMAND
ADD_CUSTOM_COMMAND(OUTPUT CUSTOM_FILES
COMMAND /usr/bin/find ARGS ${CUSTOM_PATH} -type f
COMMENT Find files
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ${CUSTOM_FILES}
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
Thanks in advance
Best Regards
NoRuleu
--
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://www.cmake.org/mailman/listinfo/cmake
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem when globbing files and using that OUTPUT variable between ADD_CUSTOM_COMMAND commands
2012/2/17 noru...@me.com
Is there no way to depend on an other custom command without using extra
files?
I don't think there is beside the fact that you can specify dependency
to a target (including custom target) or files using OUTPUT and DEPENDS options.
It would be nice if i can pass OUTPUT and TARGET to ADD_CUSTOM_COMMAND.
You can (using OUTPUT and DEPENDS) your problem is you don't
know the output of your command **statically**.
So i here is my problem in a more detail:
I want to get a list of files from
${CMAKE_RUNTIME_OUTPUT_DIR}/${PROJECT_NAME}.app where all files beginning
with ${PROJECT_NAME} would be excluded.
The result of this command is only known at build-time.
At build time the build tool (make, Visual Studio, etc...) is
running not CMake,
The objective of add_custom_ is to execute some commands **at
build-time** on behalf
of the build tool how would the build tool handle a CMake variable
while CMake is not even running ???
After that I want to iterate over that list (foreach) and run
ADD_CUSTOM_COMMAND for each file.
I see here no need for any extra files.
I think you are missing a point.
the ADD_CUSTOM_COMMAND processed by CMake when reading
CMakeLists.txt at CMake time
are ***TRANSLATED*** into build tool rules.
I think there is a need of an extra file because it's the only way to
communicate
build-time informations between several build tool rules (i.e.
derived from custom command).
The only way around I see would be for you to know ahead of build (at
CMake time)
the list of files you'll be processing.
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem when globbing files and using that OUTPUT variable between ADD_CUSTOM_COMMAND commands
Is there no way to depend on an other custom command without using extra files?
It would be nice if i can pass OUTPUT and TARGET to ADD_CUSTOM_COMMAND.
So i here is my problem in a more detail:
I want to get a list of files from
${CMAKE_RUNTIME_OUTPUT_DIR}/${PROJECT_NAME}.app where all files beginning with
${PROJECT_NAME} would be excluded.
After that I want to iterate over that list (foreach) and run
ADD_CUSTOM_COMMAND for each file.
I see here no need for any extra files.
Thanks in advance
Best Regards
NoRulez
Am 17.02.2012 um 13:47 schrieb Eric Noulard eric.noul...@gmail.com:
2012/2/17 NoRulez noru...@me.com:
Hi,
i have several ADD_CUSTOM_COMMAND commands with a specified target (let's
say TARGET1).
Between those commands I need to collect files and want to use those
collected files in the next ADD_CUSTOM_COMMAND.
How can i do that, because the following doesn't work as expected.
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
may be you could do:
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
COMMAND ${CMAKE_COMMAND} -DOutFile=fl.cmake -P
collectFiles.cmake
COMMAND ${CMAKE_COMMAND} -DInFile=fl.cmake -P
doPostProcessing.cmake
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
the collectFiles step will do whatever you want and create the fl.cmake file
which will be loaded by the second doPostProcessing in order to get
access to list of file in a pre-defined CMake var.
You can split this in separate add_custom_command but I don't see the need
in your example.
# HERE I NEED A CUSTOM COMMAND where the CUSTOM_FILES variable can be used
in the next ADD_CUSTOM_COMMAND
ADD_CUSTOM_COMMAND(OUTPUT CUSTOM_FILES
COMMAND /usr/bin/find ARGS ${CUSTOM_PATH} -type f
COMMENT Find files
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ${CUSTOM_FILES}
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
Thanks in advance
Best Regards
NoRuleu
--
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://www.cmake.org/mailman/listinfo/cmake
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] On WINDOWS, Is it Possible to build 64-bit and 32-bit Solutions in One Go?
Thanks a lot for your response! -Original Message- From: John Drescher [mailto:dresche...@gmail.com] Sent: February-16-12 3:29 PM To: Hashim Mir Cc: cmake@cmake.org Subject: Re: [CMake] On WINDOWS, Is it Possible to build 64-bit and 32-bit Solutions in One Go? On Thu, Feb 16, 2012 at 3:27 PM, John Drescher dresche...@gmail.com wrote: On Thu, Feb 16, 2012 at 2:54 PM, Hashim Mir h...@rim.com wrote: Hi, This is what I am doing presently in order to compile both a 32-bit and a 64-bit version of my project: cmake.exe -G Visual Studio 9 2008 #for x32 cmake.exe -G Visual Studio 9 2008 Win64 #for x64 Is it possible to consolidate the two individual statements into one somehow, in order to compile both 32 and 64 bit configurations of my project files with one command? No. CMake does not allow this. Only 1 generator can exist for a solution. And I mean in the same build folder tree. You can however make 2 build folder trees and use a batch file to have both build separately at the same time from the command prompt. John - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] more targets to run in parallel
So suppose I have a list of Python eggs, in the form.
- egg1
- egg2
- ..
What I would like to do is to have be able to do.
cmake .
make build_eggs
which would go over the list of the eggs and run in each of them
python setup.py bdist_egg -d some_path
The list of eggs is actually computed at run-time, so I created a custom
command and a custom target:
add_custom_command(OUTPUT ${INSTALLED_EGGS_LIST}
COMMAND ${PYTHON_EXECUTABLE} ${GEN_DEPENDENCY_SCRIPT}
${BUILD_APP_OPTIONS}
)
add_custom_target(generate_dependency_file
DEPENDS ${INSTALLED_EGGS_LIST}
)
So now, is there a way to create one target for *each* egg in the list?
And then I also need also a way to have another target that actually
depends on all these other targets, is that possible?
I could have just one target to build them all, but then it would not be
able to actually run in parallel (with make -j), is that correct?
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Generating CMake scripts from Visual Studio solutions projects?
Is there a tool to do this? All I'm looking for is something to generate a first, basic pass of the script. Doesn't have to be pretty, I just want the majority of the work to be automated. Preprocessor defines, compiler flags, include directories, dependencies, all of this should be generated in the CMake script for me, I can manage cleanup and reorganization from there. - Robert Dailey -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating CMake scripts from Visual Studio solutions projects?
2012/2/17 Robert Dailey rcdai...@gmail.com: Is there a tool to do this? All I'm looking for is something to generate a first, basic pass of the script. Doesn't have to be pretty, I just want the majority of the work to be automated. Preprocessor defines, compiler flags, include directories, dependencies, all of this should be generated in the CMake script for me, I can manage cleanup and reorganization from there. Did you try the tool listed in the Wiki http://www.cmake.org/Wiki/CMake#Visual_Studio I cannot recommend any since I'm not a Visual Studio user but you may start from there... -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating CMake scripts from Visual Studio solutions projects?
Did you try the tool listed in the Wiki http://www.cmake.org/Wiki/CMake#Visual_Studio I would be interested in if you get any of these to work well with non trivial projects. When I last looked at some of these (probably 2+ years ago so things may have changed) they did not work well with my complex visual studio projects. John -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Ralph Barth/AEH/DBS/GDB ist außer Haus. Original subject: 'CMake Digest, Vol 94, Issue 50'
Ralph Barth will be out of the office starting 17/02/2012 and will be returning on 07/03/2012. Ich werde Ihre Nachrichten nach meiner Rückkehr beantworten. WLLM related questions pls. contact Sebastian Neusüß and Jens Keil. Theo Price Feed from EDRE pls contact Jens Keil - Deutsche Börse AG Chairman of the Supervisory Board/ Vorsitzender des Aufsichtsrats: Dr. Manfred Gentz Executive Board/Vorstand: Reto Francioni (Chief Executive Officer/Vorsitzender), Andreas Preuss (Deputy Chief Executive Officer/ stellv. Vorsitzender), Frank Gerstenschläger, Michael Kuhn, Gregor Pottmeyer, Jeffrey Tessler. Aktiengesellschaft with registered seat in/mit Sitz in Frankfurt am Main. Commercial register/Handelsregister: Local court/Amtsgericht Frankfurt am Main HRB 32232. - Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating CMake scripts from Visual Studio solutions projects?
I would second that sentiment. We had more luck with writing a script to generate CMakeLists.txt file from our source tree and knowledge of what we wanted plus hand tuning the primary CMakeLists.txt file. Aaron Meadows -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of John Drescher Sent: Friday, February 17, 2012 10:48 AM To: Eric Noulard Cc: CMake ML Subject: Re: [CMake] Generating CMake scripts from Visual Studio solutions projects? Did you try the tool listed in the Wiki http://www.cmake.org/Wiki/CMake#Visual_Studio I would be interested in if you get any of these to work well with non trivial projects. When I last looked at some of these (probably 2+ years ago so things may have changed) they did not work well with my complex visual studio projects. John -- 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://www.cmake.org/mailman/listinfo/cmake This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find both shared and static versions?
On 02/17/2012 01:36 AM, Dougal Sutherland wrote:
I have an application where I want to link some targets against shared
versions of Boost and some against static versions.
(I'd prefer shared in general, but I need to link against the static
version of boost for my matlab mex interface, to avoid loading the
different version of boost shipped by matlab on runtime. I'm using this
approachhttps://github.com/mariusmuja/flann/blob/master/src/matlab/CMakeLists.txtof
a custom target calling the mex command to compile the mex file.)
FindBoost.cmake honors the Boost_USE_STATIC_LIBS variable, but that doesn't
quite solve it.
I've had the following ideas, none of which I'm happy with:
1. Use -L${Boost_LIBRARY_DIRS} and then construct the name by doing a
string replacement from .so/.dylib to .a in ${Boost_THREAD_LIBRARY}.
Definitely won't work on Windows, might not work for some types of Boost
installations on Linux/Mac, and fails at link-time instead of
configure-time if the static version doesn't exist. Maybe there's an
equivalent transformation that'll probably work on Windows; I don't know,
I'm not a Windows user.
2. Copy FindBoost.cmake to FindBoostS.cmake and replace all the
variables to use a BoostS prefix, as well as making the conditionals for
USE_STATIC_LIBS always be on; then I can run find_package(Boost) as well as
find_package(BoostS).
3. There might be some trickery to approximate (2) without actually
modifying FindBoost, but I haven't figured it out.
4. Modify FindBoost.cmake either to look for both dynamic and shared
libraries and set e.g. Boost_THREAD_LIBRARY_STATIC and
Boost_THREAD_LIBRARY_SHARED if found, or to add shared and static versions
for each component, as in
http://www.cmake.org/pipermail/cmake/2012-February/049142.html
(4) is obviously the best approach, but it's also probably much more work
than I really want to do on this.
Any suggestions? Some other approach I haven't thought of, a way to do (3),
a copy of (4) floating around somewhere?
Thanks,
Dougal
You might use multiple invocations of FIND_PACKAGE(Boost ...):
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.cxx int main(void){return 0;}\n)
# main1:
FIND_PACKAGE(Boost COMPONENTS thread)
MESSAGE(Boost_LIBRARIES: ${Boost_LIBRARIES})
ADD_EXECUTABLE(main1 main.cxx)
TARGET_LINK_LIBRARIES(main1 ${Boost_LIBRARIES})
# re-set up:
UNSET(Boost_LIBRARIES)
SET(Boost_USE_STATIC_LIBS ON)
#main2:
FIND_PACKAGE(Boost COMPONENTS regex)
MESSAGE(Boost_LIBRARIES: ${Boost_LIBRARIES})
ADD_EXECUTABLE(main2 main.cxx)
TARGET_LINK_LIBRARIES(main2 ${Boost_LIBRARIES})
The main1 target is linked against the shared thread library whereas
main2 is linked against the static regex one. Note the switch in the
Boost_USE_STATIC_LIBS variable between the two FIND_PACKAGE() calls.
IMO, FindBoost.cmake behaves bad in one regard: It accumulates results
from different invocations within the same scope. For this reason, you
must intermediately unset the Boost_LIBRARIES variable - and probably
all further uncached result variables like Boost_INCLUDE_DIRS also.
Otherwise, main2 would be linked against the shared thread library,
too, although the latter has not been requested by the latest FIND_
PACKAGE() call. With Boost, AFAIK, it's sufficient to simply reset
the uncached result variables, but with {Find,Use}Qt4.cmake, e.g.,
and their QT_USE_QT* variables, it's a real annoyance to link two
targets against different sets of Qt modules within the same scope.
In summary, my vision of an improved FindBoost.cmake comprises:
- Explicitly shared and static components, e.g. thread_shared and
regex_static, so one can specifically select them even in mixed
cases: FIND_PACKAGE(Boost COMPONENTS thread_shared regex_static)
- For convenience and backward compatibility, the usual components
like thread and regex as always, with Boost_USE_STATIC_LIBS
deciding whether component X is turned into X_shared or X_static.
AFAICS, this can be accomplished as a kind of preprocessing the
Boost_FIND_COMPONENTS variable quite early in FindBoost.cmake.
- No accumulation of uncached results across multiple invocations
of FindBoost.cmake; in other words: The uncached results should
depend only on the parameters of the FindBoost.cmake invocation,
i.e. the components list, well-known variables as CMAKE_MODULE_
PATH and well-documented ones as BOOST_ROOT - though the latter
isn't mentioned in FindBoost.cmake's online documentation ATM.
In contrast, results of previous FindBoost.cmake calls should
not show up in the uncached result variables for exactly the
reason mentioned above.
Feel free to file a feature request; maybe, PL can be persuaded. ;)
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
thank you Eric, I try to do what you explained,I don't if I got it correctlyI got the same message, may I miss something OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txtI did the following things:1-create a folder pCMake1 and put CMakeLists.txt and main.cpp2-create a bin foler in pCMake13-run cmake-gui and put source code c:/pCMake1binaries c:/pCMakes1/Binthen push Generate it asks:specify generator : CodeBlocks -MinGW MakesFilescheck use default native compilerI check that the path variable are there CMake2.8 and CodeBlocks/MinGWand I get:CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER_ENV_VAR Message d'origine De : "Eric Noulard" eric.noul...@gmail.com À : paspa...@noos.fr Objet : Re: Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles Date : 17/02/2012 13:18:15 CET Copie à : cmake@cmake.org 2012/2/17 paspa...@noos.fr: Hello Eric, thank you for your suggestions and support I am going to try to detail more what I did: - Install CMake on Program Files/CMake 2.8/bin - Install CodeBlocks with its windows installer at the same time he asks if we want the gcc compiler I said ok and he installed MinGW in Program Files/CodeBlocks/MinGW - as you suggested he didn't set the path variable so now the path variable are: C:\Program Files\CMake 2.8\bin;C:\Program Files\CodeBlocks\MinGW; - I created a codeblock printhello project named pCMake then at this step I didn't know what to do exactly: First Attempt: I put a CMakeLists.txt file in the codeblocks "Others" folders with the file containing: cmake_minimum_required(2.8) project(pCMake) add_executable(pCMake main.cpp) and in the Project Properties/Project Settings : I set : Makefile:CMakeLists and check "This is a custom MakeFile" OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txt May be you could read the beginning of thoses documents: http://www.cmake.org/cmake/help/cmake_tutorial.html https://github.com/TheErk/CMake-tutorial/raw/master/CMake-tutorial-8feb2012.p df in order to have a better idea of the CMake workflow. Second Attempt: use CMake cmake-gui interface where is the source code:C:\pCMake where to buid the binaries:C:\pCMake It is better habit to have separate directories for sources and binaries. see: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees I push the button: Generate specify the generator for this project: select in the combo :CodeBlocks-MinGW MakeFiles check Use Default native compilers result: CMake Error at CMakeLists.txt:1 (cmake_minimum_required): cmake_minimum_required called with unknown argument "2.8" you have a syntax error in your CMakeLists.txt you should write cmake_minimum_required(VERSION 2.8) read on the documentation: http://www.cmake.org/cmake/help/documentation.html CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. find "make.exe" program in your Code::Blocks install and add the path to it to your PATH. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
2012/2/17 paspa...@noos.fr: thank you Eric, I try to do what you explained,I don't if I got it correctly I got the same message, may I miss something OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txt I did the following things: 1-create a folder pCMake1 and put CMakeLists.txt and main.cpp 2-create a bin foler in pCMake1 3-run cmake-gui and put source code c:/pCMake1 binaries c:/pCMakes1/Bin that part is ok. then push Generate it asks: specify generator : CodeBlocks -MinGW MakesFiles check use default native compiler I check that the path variable are there CMake2.8 and CodeBlocks/MinGW PATH should contains path to make.exe and gcc.exe Is make.exe in CodeBlocks/MinGW ? May be it is not there but in a subdirectory of CodeBlocks/MinGW? Please avoid complete top-posting this make the message less readable. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] symbolic links
Thanks Eric, This solution should work and Unix is the only place where I need this to happen anyway. On Fri, Feb 17, 2012 at 12:23 PM, Eric Noulard eric.noul...@gmail.comwrote: 2012/2/17 Steven Wilson steven.wesley.wil...@gmail.com: I have a large software system that depends on third party libraries. The CMake system that builds this software uses install() to copy these libraries into the appropriate place in the layout. On some systems I would like to provide my developers with the option of not copying these libraries and instead creating symbolic links to the libraries in the software layout. Using symbolic links would save a great deal of disk space for developers when they have many different versions(debug, profile, etc...) of the software build system.Is there a way to create symbolic links to files rather than copy files at install time? You could certainly achieve that using install(CODE or install(SCRIPT and execute_process with cmake -E create_symlink that said it will only work on unix. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
Eric thank you very much it was also your last suggestions which was rigththe compiler is placed in a bin folder of MinGWthe generation is done,I have to continue in codeblocks nowthanks againpascal Message d'origine De : "Eric Noulard" eric.noul...@gmail.com À : paspa...@noos.fr Objet : Re: Re: Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles Date : 17/02/2012 22:00:58 CET Copie à : cmake@cmake.org 2012/2/17 paspa...@noos.fr: thank you Eric, I try to do what you explained,I don't if I got it correctly I got the same message, may I miss something OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txt I did the following things: 1-create a folder pCMake1 and put CMakeLists.txt and main.cpp 2-create a bin foler in pCMake1 3-run cmake-gui and put source code c:/pCMake1 binaries c:/pCMakes1/Bin that part is ok. then push Generate it asks: specify generator : CodeBlocks -MinGW MakesFiles check use default native compiler I check that the path variable are there CMake2.8 and CodeBlocks/MinGW PATH should contains path to make.exe and gcc.exe Is make.exe in CodeBlocks/MinGW ? May be it is not there but in a subdirectory of CodeBlocks/MinGW? Please avoid complete top-posting this make the message less readable. -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2673-gf131113
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f131113d11ca69ec71f090b402fbd04a38e14c41 (commit)
via fd866f01d484c14b57eb3c2619a06142d6ac85df (commit)
via d46bce95aa3bba22f921906bf74afacc3b6251c9 (commit)
via 2a48331e5d1ba855429b8c35e832143f18764e1b (commit)
via d03606a19cc05872baf23269ae8ec61d2e0719e8 (commit)
from ffdef8726313f88bcfc534f37a989db8c5b93c47 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f131113d11ca69ec71f090b402fbd04a38e14c41
commit f131113d11ca69ec71f090b402fbd04a38e14c41
Merge: ffdef87 fd866f0
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 05:47:48 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 17 05:47:48 2012 -0500
Merge topic 'FindPackage_ImprovedErrorMessages' into next
fd866f0 find_package: print the error message if an invalid CONFIGS name is
used
d46bce9 find_package(): improved error message, mention version number
2a48331 find_package(): improved error message mentioning CMAKE_PREFIX_PATH
d03606a KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd866f01d484c14b57eb3c2619a06142d6ac85df
commit fd866f01d484c14b57eb3c2619a06142d6ac85df
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 11:43:27 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Feb 17 11:45:24 2012 +0100
find_package: print the error message if an invalid CONFIGS name is used
Alex
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index c3e472b..a166f89 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -538,6 +538,7 @@ bool cmFindPackageCommand
e given CONFIGS option followed by invalid file name \
args[i] \. The names given must be file names without
a path and with a \.cmake\ extension.;
+this-SetError(e.str().c_str());
return false;
}
this-Configs.push_back(args[i]);
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d46bce95aa3bba22f921906bf74afacc3b6251c9
commit d46bce95aa3bba22f921906bf74afacc3b6251c9
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 11:37:29 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Feb 17 11:45:18 2012 +0100
find_package(): improved error message, mention version number
Now when Find-module or the config file have not been found at all,
the required version is printed too, so the user knows which version
of the package he has to install:
CMake Error at CMakeLists.txt:7 (find_package):
Could not find a configuration file for package ecm
(requested version 0.0.4) with one of the following names:
ecmConfig.cmake
ecm-config.cmake
To find the configuration file, set CMAKE_PREFIX_PATH to the installation
prefix of ecm, or set ecm_DIR to the
directory containing a CMake configuration file for ecm.
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index 4fcb4e7..c3e472b 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -911,6 +911,14 @@ bool cmFindPackageCommand::HandlePackageMode()
}
else
{
+ std::string requestedVersionString;
+ if(!this-Version.empty())
+{
+requestedVersionString = (requested version ;
+requestedVersionString += this-Version;
+requestedVersionString += );
+}
+
e Could not find ;
if(!this-NoModule)
{
@@ -919,11 +927,12 @@ bool cmFindPackageCommand::HandlePackageMode()
if(this-Configs.size() == 1)
{
e a configuration file named this-Configs[0]
-for package this-Name .\n;
+for package this-Name requestedVersionString .\n;
}
else
{
e a configuration file for package this-Name
+ requestedVersionString
with one of the following names:\n;
for(std::vectorstd::string::const_iterator ci=this-Configs.begin();
ci != this-Configs.end(); ++ci)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a48331e5d1ba855429b8c35e832143f18764e1b
commit 2a48331e5d1ba855429b8c35e832143f18764e1b
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 11:26:03 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Feb 17 11:26:03 2012 +0100
find_package(): improved error message mentioning CMAKE_PREFIX_PATH
Now
[Cmake-commits] CMake branch, next, updated. v2.8.7-2676-ga341fe5
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a341fe5a8f14f9fbf314e7ac927795ba38ef8c13 (commit)
via 939991dbe6350eb0d9ac8983be67c776fce0baad (commit)
via ba1ea104670df8cb86728c4d0fb4ca48d45364af (commit)
from f131113d11ca69ec71f090b402fbd04a38e14c41 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a341fe5a8f14f9fbf314e7ac927795ba38ef8c13
commit a341fe5a8f14f9fbf314e7ac927795ba38ef8c13
Merge: f131113 939991d
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 10:44:38 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 17 10:44:38 2012 -0500
Merge topic 'HandleTargetsInCMakeRequiredLibraries' into next
939991d fix bootstrap: move while() and endwhile() into the bootstrap build
ba1ea10 strip trailing whitespace
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=939991dbe6350eb0d9ac8983be67c776fce0baad
commit 939991dbe6350eb0d9ac8983be67c776fce0baad
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 16:42:06 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Feb 17 16:42:06 2012 +0100
fix bootstrap: move while() and endwhile() into the bootstrap build
Alex
diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx
index cb5dc4c..9097a74 100644
--- a/Source/cmBootstrapCommands.cxx
+++ b/Source/cmBootstrapCommands.cxx
@@ -38,6 +38,7 @@
#include cmEndFunctionCommand.cxx
#include cmEndIfCommand.cxx
#include cmEndMacroCommand.cxx
+#include cmEndWhileCommand.cxx
#include cmExecProgramCommand.cxx
#include cmExecuteProcessCommand.cxx
#include cmExternalMakefileProjectGenerator.cxx
@@ -91,6 +92,7 @@
#include cmTryCompileCommand.cxx
#include cmTryRunCommand.cxx
#include cmUnsetCommand.cxx
+#include cmWhileCommand.cxx
void GetBootstrapCommands(std::listcmCommand* commands)
{
@@ -116,6 +118,7 @@ void GetBootstrapCommands(std::listcmCommand* commands)
commands.push_back(new cmEndFunctionCommand);
commands.push_back(new cmEndIfCommand);
commands.push_back(new cmEndMacroCommand);
+ commands.push_back(new cmEndWhileCommand);
commands.push_back(new cmExecProgramCommand);
commands.push_back(new cmExecuteProcessCommand);
commands.push_back(new cmFileCommand);
@@ -164,4 +167,5 @@ void GetBootstrapCommands(std::listcmCommand* commands)
commands.push_back(new cmTryCompileCommand);
commands.push_back(new cmTryRunCommand);
commands.push_back(new cmUnsetCommand);
+ commands.push_back(new cmWhileCommand);
}
diff --git a/Source/cmCommands.cxx b/Source/cmCommands.cxx
index bb1e4e2..49ed967 100644
--- a/Source/cmCommands.cxx
+++ b/Source/cmCommands.cxx
@@ -14,7 +14,6 @@
#include cmAuxSourceDirectoryCommand.cxx
#include cmBuildNameCommand.cxx
#include cmElseIfCommand.cxx
-#include cmEndWhileCommand.cxx
#include cmExportCommand.cxx
#include cmExportLibraryDependencies.cxx
#include cmFLTKWrapUICommand.cxx
@@ -34,7 +33,6 @@
#include cmVariableRequiresCommand.cxx
#include cmVariableWatchCommand.cxx
-#include cmWhileCommand.cxx
#include cmWriteFileCommand.cxx
// This one must be last because it includes windows.h and
@@ -53,7 +51,6 @@ void GetPredefinedCommands(std::listcmCommand*
commands.push_back(new cmAuxSourceDirectoryCommand);
commands.push_back(new cmBuildNameCommand);
commands.push_back(new cmElseIfCommand);
- commands.push_back(new cmEndWhileCommand);
commands.push_back(new cmExportCommand);
commands.push_back(new cmExportLibraryDependenciesCommand);
commands.push_back(new cmFLTKWrapUICommand);
@@ -73,7 +70,6 @@ void GetPredefinedCommands(std::listcmCommand*
commands.push_back(new cmUtilitySourceCommand);
commands.push_back(new cmVariableRequiresCommand);
commands.push_back(new cmVariableWatchCommand);
- commands.push_back(new cmWhileCommand);
commands.push_back(new cmWriteFileCommand);
#endif
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ba1ea104670df8cb86728c4d0fb4ca48d45364af
commit ba1ea104670df8cb86728c4d0fb4ca48d45364af
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Feb 17 16:41:14 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Feb 17 16:41:14 2012 +0100
strip trailing whitespace
Alex
diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx
index 554f452..cb5dc4c 100644
--- a/Source/cmBootstrapCommands.cxx
+++ b/Source/cmBootstrapCommands.cxx
@@ -12,7 +12,7 @@
// This file is used to compile all the commands
// that CMake knows about at compile time.
// This is sort of a boot strapping approach since you
[Cmake-commits] CMake branch, next, updated. v2.8.7-2678-g21b4d11
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 21b4d1168a86a62b21490c85acb9a4746bda4b2a (commit)
via ba89e92ba622ed821a6adf31e8a6633d574ff656 (commit)
from a341fe5a8f14f9fbf314e7ac927795ba38ef8c13 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21b4d1168a86a62b21490c85acb9a4746bda4b2a
commit 21b4d1168a86a62b21490c85acb9a4746bda4b2a
Merge: a341fe5 ba89e92
Author: David Cole david.c...@kitware.com
AuthorDate: Fri Feb 17 11:32:21 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 17 11:32:21 2012 -0500
Merge topic 'fix-12189-support-SBCS-in-VS' into next
ba89e92 Visual Studio: Allow setting Single Byte Character Set (#12189)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ba89e92ba622ed821a6adf31e8a6633d574ff656
commit ba89e92ba622ed821a6adf31e8a6633d574ff656
Author: Aaron C. Meadows cor...@shadowguarddev.com
AuthorDate: Thu Feb 16 15:27:05 2012 -0600
Commit: David Cole david.c...@kitware.com
CommitDate: Fri Feb 17 11:30:23 2012 -0500
Visual Studio: Allow setting Single Byte Character Set (#12189)
For Visual Studio using the Preprocessor Define _SBCS. This behavior
is similar to the way that _UNICODE and _MBCS work already.
Added tests to confirm this behavior.
diff --git a/Source/cmLocalVisualStudio7Generator.cxx
b/Source/cmLocalVisualStudio7Generator.cxx
index 11a0387..a23d6a1 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -774,6 +774,10 @@ void
cmLocalVisualStudio7Generator::WriteConfiguration(std::ostream fout,
{
fout \t\t\tCharacterSet=\1\\n;
}
+ else if(targetOptions.UsingSBCS())
+{
+fout \t\t\tCharacterSet=\0\\n;
+}
else
{
fout \t\t\tCharacterSet=\2\\n;
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index 9418761..ab74265 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -394,6 +394,11 @@ void
cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues()
{
this-WriteString(CharacterSetUnicode/CharacterSet\n, 2);
}
+else if (this-Target-GetType() = cmTarget::MODULE_LIBRARY
+ this-ClOptions[*i]-UsingSBCS())
+ {
+ this-WriteString(CharacterSetNotSet/CharacterSet\n, 2);
+ }
else
{
this-WriteString(CharacterSetMultiByte/CharacterSet\n, 2);
diff --git a/Source/cmVisualStudioGeneratorOptions.cxx
b/Source/cmVisualStudioGeneratorOptions.cxx
index 41230e7..9369af6 100644
--- a/Source/cmVisualStudioGeneratorOptions.cxx
+++ b/Source/cmVisualStudioGeneratorOptions.cxx
@@ -117,6 +117,20 @@ bool cmVisualStudioGeneratorOptions::UsingUnicode()
}
return false;
}
+//
+bool cmVisualStudioGeneratorOptions::UsingSBCS()
+{
+ // Look for the a _SBCS definition.
+ for(std::vectorstd::string::const_iterator di = this-Defines.begin();
+ di != this-Defines.end(); ++di)
+{
+if(*di == _SBCS)
+ {
+ return true;
+ }
+}
+ return false;
+}
//
void cmVisualStudioGeneratorOptions::Parse(const char* flags)
diff --git a/Source/cmVisualStudioGeneratorOptions.h
b/Source/cmVisualStudioGeneratorOptions.h
index 51a1362..a1a55da 100644
--- a/Source/cmVisualStudioGeneratorOptions.h
+++ b/Source/cmVisualStudioGeneratorOptions.h
@@ -48,6 +48,7 @@ public:
// Check for specific options.
bool UsingUnicode();
+ bool UsingSBCS();
bool IsDebug();
// Write options to output.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 9c97828..da656d4 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1306,6 +1306,8 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
endif()
IF(${CMAKE_TEST_GENERATOR} MATCHES Visual Studio)
+ADD_TEST_MACRO(SBCS SBCS)
+
ADD_TEST(VSExternalInclude ${CMAKE_CTEST_COMMAND}
--build-and-test
${CMake_SOURCE_DIR}/Tests/VSExternalInclude
diff --git a/Tests/SBCS/CMakeLists.txt b/Tests/SBCS/CMakeLists.txt
new file mode 100644
index 000..b3c3c2c
--- /dev/null
+++ b/Tests/SBCS/CMakeLists.txt
@@ -0,0 +1,6 @@
+# a SBCS test case
+project (SBCS)
+
+add_definitions(-D_SBCS)
+
+add_executable (SBCS SBCS.cxx)
diff --git a/Tests/SBCS/SBCS.cxx b/Tests/SBCS/SBCS.cxx
new file mode 100644
index 000..6ce2c9f
--- /dev/null
+++ b/Tests/SBCS/SBCS.cxx
@@ -0,0 +1,22 @@
[Cmake-commits] CMake branch, next, updated. v2.8.7-2680-gb8bc894
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via b8bc894ae032747a8b6e127d5fb291ae28d4fbd1 (commit)
via 4fbdce2b79b28566ae2c6708c99af5e0e8e0177b (commit)
from 21b4d1168a86a62b21490c85acb9a4746bda4b2a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8bc894ae032747a8b6e127d5fb291ae28d4fbd1
commit b8bc894ae032747a8b6e127d5fb291ae28d4fbd1
Merge: 21b4d11 4fbdce2
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Feb 17 11:57:11 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 17 11:57:11 2012 -0500
Merge topic 'try-compile-random-name' into next
4fbdce2 try_compile: Use random executable file name (#12957)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4fbdce2b79b28566ae2c6708c99af5e0e8e0177b
commit 4fbdce2b79b28566ae2c6708c99af5e0e8e0177b
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Feb 13 10:02:58 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Feb 16 10:13:50 2012 -0500
try_compile: Use random executable file name (#12957)
Append a random number to the cmTryCompileExec file name to avoid
rapid creation and deletion of the same executable file name. Some
filesystems lock executable files when they are created and cause
subsequent try-compile tests to fail arbitrarily. Use a different
name each time to avoid conflict.
diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx
index dca2fb3..7d84ba6 100644
--- a/Source/cmCoreTryCompile.cxx
+++ b/Source/cmCoreTryCompile.cxx
@@ -26,6 +26,7 @@ int cmCoreTryCompile::TryCompileCode(std::vectorstd::string
const argv)
const char* sourceDirectory = argv[2].c_str();
const char* projectName = 0;
const char* targetName = 0;
+ char targetNameBuf[64];
int extraArgs = 0;
// look for CMAKE_FLAGS and store them
@@ -281,16 +282,20 @@ int
cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv)
cmakeFlags.push_back(flag);
}
+/* Use a random file name to avoid rapid creation and deletion
+ of the same executable name (some filesystems fail on that). */
+sprintf(targetNameBuf, cmTryCompileExec%u,
+cmSystemTools::RandomSeed());
+targetName = targetNameBuf;
+
/* Put the executable at a known location (for COPY_FILE). */
fprintf(fout, SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY \%s\)\n,
this-BinaryDirectory.c_str());
/* Create the actual executable. */
-fprintf(fout, ADD_EXECUTABLE(cmTryCompileExec \%s\)\n,source.c_str());
-fprintf(fout,
-TARGET_LINK_LIBRARIES(cmTryCompileExec ${LINK_LIBRARIES})\n);
+fprintf(fout, ADD_EXECUTABLE(%s \%s\)\n, targetName, source.c_str());
+fprintf(fout, TARGET_LINK_LIBRARIES(%s ${LINK_LIBRARIES})\n,targetName);
fclose(fout);
projectName = CMAKE_TRY_COMPILE;
-targetName = cmTryCompileExec;
// if the source is not in CMakeTmp
if(source.find(CMakeTmp) == source.npos)
{
---
Summary of changes:
Source/cmCoreTryCompile.cxx | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-2684-gfcfb7c9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via fcfb7c98570673f29de75612a784edcefdff6573 (commit)
via 70697a85a0bd273c0b1773471b7ae11b2c7ceb57 (commit)
from 6be7e46577ff4ab63f70b924dd8ed6c3fe2a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fcfb7c98570673f29de75612a784edcefdff6573
commit fcfb7c98570673f29de75612a784edcefdff6573
Merge: 6be7e46 70697a8
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Feb 17 12:17:27 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 17 12:17:27 2012 -0500
Merge topic 'improve-findlibxslt' into next
70697a8 FindLibXslt: support version selection
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70697a85a0bd273c0b1773471b7ae11b2c7ceb57
commit 70697a85a0bd273c0b1773471b7ae11b2c7ceb57
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Feb 17 18:16:35 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Fri Feb 17 18:17:12 2012 +0100
FindLibXslt: support version selection
diff --git a/Modules/FindLibXslt.cmake b/Modules/FindLibXslt.cmake
index 1e42f42..dd5aac4 100644
--- a/Modules/FindLibXslt.cmake
+++ b/Modules/FindLibXslt.cmake
@@ -5,6 +5,7 @@
# LIBXSLT_INCLUDE_DIR - the LibXslt include directory
# LIBXSLT_LIBRARIES - Link these to LibXslt
# LIBXSLT_DEFINITIONS - Compiler switches required for using LibXslt
+# LIBXSLT_VERSION_STRING - version of LibXslt found (since CMake 2.8.8)
# Additionally, the following two variables are set (but not required for
using xslt):
# LIBXSLT_EXSLT_LIBRARIES - Link to these if you need to link against the
exslt library
# LIBXSLT_XSLTPROC_EXECUTABLE - Contains the full path to the xsltproc
executable if found
@@ -51,10 +52,21 @@ SET(LIBXSLT_EXSLT_LIBRARIES ${LIBXSLT_EXSLT_LIBRARY} )
FIND_PROGRAM(LIBXSLT_XSLTPROC_EXECUTABLE xsltproc)
-# handle the QUIETLY and REQUIRED arguments and set LIBXML2_FOUND to TRUE if
-# all listed variables are TRUE
+IF(PC_LIBXSLT_VERSION)
+SET(LIBXSLT_VERSION_STRING ${PC_LIBXSLT_VERSION})
+ELSEIF(LIBXSLT_INCLUDE_DIR AND EXISTS
${LIBXSLT_INCLUDE_DIR}/libxslt/xsltconfig.h)
+FILE(STRINGS ${LIBXSLT_INCLUDE_DIR}/libxslt/xsltconfig.h
libxslt_version_str
+ REGEX ^#define[\t ]+LIBXSLT_DOTTED_VERSION[\t ]+\.*\)
+
+STRING(REGEX REPLACE ^#define[\t ]+LIBXSLT_DOTTED_VERSION[\t
]+\([^\]*)\.* \\1
+ LIBXSLT_VERSION_STRING ${libxslt_version_str})
+UNSET(libxslt_version_str)
+ENDIF()
+
INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-FIND_PACKAGE_HANDLE_STANDARD_ARGS(LibXslt DEFAULT_MSG LIBXSLT_LIBRARIES
LIBXSLT_INCLUDE_DIR)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(LibXslt
+ REQUIRED_VARS LIBXSLT_LIBRARIES
LIBXSLT_INCLUDE_DIR
+ VERSION_VAR LIBXSLT_VERSION_STRING)
MARK_AS_ADVANCED(LIBXSLT_INCLUDE_DIR
LIBXSLT_LIBRARIES
---
Summary of changes:
Modules/FindLibXslt.cmake | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-2687-g0f856c5
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0f856c54befc47dc4b9238e5a877435b27135f91 (commit)
via bb1ba19ed73ef1e5dce10c69adbf57daa83b683b (commit)
via f58cce031e7c641c0ae216a66595837eb1b4dee7 (commit)
from fcfb7c98570673f29de75612a784edcefdff6573 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f856c54befc47dc4b9238e5a877435b27135f91
commit 0f856c54befc47dc4b9238e5a877435b27135f91
Merge: fcfb7c9 bb1ba19
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Feb 17 12:47:00 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 17 12:47:00 2012 -0500
Merge topic 'improve-findfreetype' into next
bb1ba19 AllFindModules test: be strict about FREETYPE and LibXslt version
f58cce0 FindFreetype: support version selection
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb1ba19ed73ef1e5dce10c69adbf57daa83b683b
commit bb1ba19ed73ef1e5dce10c69adbf57daa83b683b
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Feb 17 18:46:23 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Fri Feb 17 18:46:23 2012 +0100
AllFindModules test: be strict about FREETYPE and LibXslt version
Enforce the version to be found if the library is found, at least for the
moment.
This makes it easy to see if there are cases that are not covered by the
current
code.
diff --git a/Tests/CMakeOnly/AllFindModules/CMakeLists.txt
b/Tests/CMakeOnly/AllFindModules/CMakeLists.txt
index f76f0d9..373470f 100644
--- a/Tests/CMakeOnly/AllFindModules/CMakeLists.txt
+++ b/Tests/CMakeOnly/AllFindModules/CMakeLists.txt
@@ -48,8 +48,8 @@ endif (NOT QT4_FOUND)
# If any of these modules reported that it was found a version number should
have been
# reported.
set(VERSIONS_REQUIRED
-ALSA BISON BZIP2 CUPS CURL DOXYGEN EXPAT FLEX GETTEXT GIF GIT
-ImageMagick JASPER LibArchive LIBXML2 PERL PostgreSQL SWIG TIFF ZLIB)
+ALSA BISON BZIP2 CUPS CURL DOXYGEN EXPAT FLEX FREETYPE GETTEXT GIF GIT
+ImageMagick JASPER LibArchive LIBXML2 LIBXSLT PERL PostgreSQL SWIG TIFF
ZLIB)
foreach(VTEST ${VERSIONS_REQUIRED})
if (${VTEST}_FOUND)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f58cce031e7c641c0ae216a66595837eb1b4dee7
commit f58cce031e7c641c0ae216a66595837eb1b4dee7
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Fri Feb 17 18:31:23 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Fri Feb 17 18:31:23 2012 +0100
FindFreetype: support version selection
diff --git a/Modules/FindFreetype.cmake b/Modules/FindFreetype.cmake
index 6251805..e6f6702 100644
--- a/Modules/FindFreetype.cmake
+++ b/Modules/FindFreetype.cmake
@@ -3,6 +3,7 @@
# FREETYPE_LIBRARIES, the library to link against
# FREETYPE_FOUND, if false, do not try to link to FREETYPE
# FREETYPE_INCLUDE_DIRS, where to find headers.
+# FREETYPE_VERSION_STRING, the version of freetype found (since CMake 2.8.8)
# This is the concatenation of the paths:
# FREETYPE_INCLUDE_DIR_ft2build
# FREETYPE_INCLUDE_DIR_freetype2
@@ -77,10 +78,33 @@ IF(FREETYPE_INCLUDE_DIR_ft2build AND
FREETYPE_INCLUDE_DIR_freetype2)
ENDIF(FREETYPE_INCLUDE_DIR_ft2build AND FREETYPE_INCLUDE_DIR_freetype2)
SET(FREETYPE_LIBRARIES ${FREETYPE_LIBRARY})
+IF(FREETYPE_INCLUDE_DIR_freetype2 AND EXISTS
${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h)
+FILE(STRINGS ${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h
freetype_version_str
+ REGEX ^#[\t ]*define[\t ]+FREETYPE_(MAJOR|MINOR|PATCH)[\t ]+[0-9]+$)
+
+UNSET(FREETYPE_VERSION_STRING)
+FOREACH(VPART MAJOR MINOR PATCH)
+FOREACH(VLINE ${freetype_version_str})
+IF(VLINE MATCHES ^#[\t ]*define[\t ]+FREETYPE_${VPART})
+STRING(REGEX REPLACE ^#[\t ]*define[\t ]+FREETYPE_${VPART}[\t
]+([0-9]+)$ \\1
+ FREETYPE_VERSION_PART ${VLINE})
+IF(FREETYPE_VERSION_STRING)
+SET(FREETYPE_VERSION_STRING
${FREETYPE_VERSION_STRING}.${FREETYPE_VERSION_PART})
+ELSE(FREETYPE_VERSION_STRING)
+SET(FREETYPE_VERSION_STRING ${FREETYPE_VERSION_PART})
+ENDIF(FREETYPE_VERSION_STRING)
+UNSET(FREETYPE_VERSION_PART)
+ENDIF()
+ENDFOREACH(VLINE)
+ENDFOREACH(VPART)
+ENDIF(FREETYPE_INCLUDE_DIR_freetype2 AND EXISTS
${FREETYPE_INCLUDE_DIR_freetype2}/freetype/freetype.h)
+
+
# handle the QUIETLY and REQUIRED arguments and set FREETYPE_FOUND to TRUE if
# all listed variables are TRUE
[Cmake-commits] CMake branch, master, updated. v2.8.7-379-gbfbb575
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via bfbb57508603ab6c7007d75718b21868b690e151 (commit) from d03606a19cc05872baf23269ae8ec61d2e0719e8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bfbb57508603ab6c7007d75718b21868b690e151 commit bfbb57508603ab6c7007d75718b21868b690e151 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Feb 18 00:05:12 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Feb 18 00:05:12 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index c80c53f..2bf0e14 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 02) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 17) +SET(KWSYS_DATE_STAMP_DAY 18) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
