[cmake-developers] [PATCH 1/3] CPackRPM: Fix CPACK_RPM_PACKAGE_ARCHITECTURE
BuildArch must only be added to a spec file for a noarch package
or rpmbuild will fail.
For all others, the --target argument sets the package architecture
In the process of Fixing rpm architecture, we make it mandatory,
adding a default value of native architecture (the same as if no
--target argument is present)
Update the documentation at the top of the file to mandatory.
---
Modules/CPackRPM.cmake | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 7516393..5135893 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -54,8 +54,8 @@
#
# The RPM package architecture.
#
-# * Mandatory : NO
-# * Default : -
+# * Mandatory : YES
+# * Default : Native architecture output by uname -m
#
# This may be set to noarch if you know you are building a noarch package.
#
@@ -619,12 +619,21 @@ endif()
# RPM Version from RPM Release
string(REPLACE - _ CPACK_RPM_PACKAGE_VERSION ${CPACK_RPM_PACKAGE_VERSION})
-# CPACK_RPM_PACKAGE_ARCHITECTURE (optional)
-if(CPACK_RPM_PACKAGE_ARCHITECTURE)
- set(TMP_RPM_BUILDARCH Buildarch: ${CPACK_RPM_PACKAGE_ARCHITECTURE})
+# CPACK_RPM_PACKAGE_ARCHITECTURE (mandatory)
+if (NOT CPACK_RPM_PACKAGE_ARCHITECTURE)
+ execute_process(COMMAND uname -m
+ OUTPUT_VARIABLE CPACK_RPM_PACKAGE_ARCHITECTURE
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+else()
if(CPACK_RPM_PACKAGE_DEBUG)
message(CPackRPM:Debug: using user-specified build arch =
${CPACK_RPM_PACKAGE_ARCHITECTURE})
endif()
+endif()
+if (NOT CPACK_RPM_PACKAGE_ARCHITECTURE_)
+ set(CPACK_RPM_PACKAGE_ARCHITECTURE_ ${CPACK_RPM_PACKAGE_ARCHITECTURE})
+endif()
+if(${CPACK_RPM_PACKAGE_ARCHITECTURE_} STREQUAL noarch)
+ set(TMP_RPM_BUILDARCH Buildarch: ${CPACK_RPM_PACKAGE_ARCHITECTURE_})
else()
set(TMP_RPM_BUILDARCH )
endif()
@@ -934,7 +943,7 @@ file(MAKE_DIRECTORY ${CPACK_RPM_ROOTDIR}/SOURCES)
file(MAKE_DIRECTORY ${CPACK_RPM_ROOTDIR}/SPECS)
file(MAKE_DIRECTORY ${CPACK_RPM_ROOTDIR}/SRPMS)
-#set(CPACK_RPM_FILE_NAME
${CPACK_RPM_PACKAGE_NAME}-${CPACK_RPM_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}-${CPACK_RPM_PACKAGE_ARCHITECTURE}.rpm)
+#set(CPACK_RPM_FILE_NAME
${CPACK_RPM_PACKAGE_NAME}-${CPACK_RPM_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}-${CPACK_RPM_PACKAGE_ARCHITECTURE_}.rpm)
set(CPACK_RPM_FILE_NAME ${CPACK_OUTPUT_FILE_NAME})
# it seems rpmbuild can't handle spaces in the path
# neither escaping (as below) nor putting quotes around the path seem to help
@@ -1282,6 +1291,7 @@ if(RPMBUILD_EXECUTABLE)
COMMAND ${RPMBUILD_EXECUTABLE} -bb
--define _topdir ${CPACK_RPM_DIRECTORY}
--buildroot
${CPACK_RPM_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH}
+--target ${CPACK_RPM_PACKAGE_ARCHITECTURE_}
${CPACK_RPM_BINARY_SPECFILE}
WORKING_DIRECTORY
${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH}
RESULT_VARIABLE CPACK_RPMBUILD_EXEC_RESULT
--
2.2.2
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 3/3] Tests: CpackRPM test component architecture
Test creating rpms of type noarch, native, and armv7hf
---
Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in | 6 ++
Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake| 8
2 files changed, 14 insertions(+)
diff --git a/Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in
b/Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in
index de0ee46..c2ac1c5 100644
--- a/Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in
+++ b/Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in
@@ -8,9 +8,15 @@ endif()
if(CPACK_GENERATOR MATCHES RPM)
set(CPACK_PACKAGING_INSTALL_PREFIX /usr)
+ # test a noarch rpm
+ set(CPACK_RPM_headers_PACKAGE_ARCHITECTURE noarch)
+
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_RPM_applications_PACKAGE_REQUIRES mylib-libraries)
+ # test cross-built rpm
+ set(CPACK_RPM_applications_PACKAGE_ARCHITECTURE armv7hf)
+
# test package summary override
set(CPACK_RPM_PACKAGE_SUMMARY default summary)
set(CPACK_RPM_libraries_PACKAGE_SUMMARY libraries summary)
diff --git a/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
b/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
index 68d846f..5be9d17 100644
--- a/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
+++ b/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
@@ -161,21 +161,25 @@ if(CPackGen MATCHES RPM)
set(check_file_match_expected_summary
.*${CPACK_RPM_libraries_PACKAGE_SUMMARY}.*)
set(check_file_match_expected_description
.*${CPACK_RPM_libraries_PACKAGE_DESCRIPTION}.*)
set(check_file_match_expected_relocation_path Relocations :
${CPACK_PACKAGING_INSTALL_PREFIX}
${CPACK_PACKAGING_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR})
+set(check_file_match_expected_architecture Architecture:
${CPACK_RPM_applications_PACKAGE_ARCHITECTURE})
set(spec_regex *libraries*)
elseif(check_file_headers_match)
set(check_file_match_expected_summary
.*${CPACK_RPM_PACKAGE_SUMMARY}.*)
set(check_file_match_expected_description
.*${CPACK_COMPONENT_HEADERS_DESCRIPTION}.*)
set(check_file_match_expected_relocation_path Relocations :
${CPACK_PACKAGING_INSTALL_PREFIX}
${CPACK_PACKAGING_INSTALL_PREFIX}/${CMAKE_INSTALL_INCLUDEDIR})
+set(check_file_match_expected_architecture Architecture:
${CPACK_RPM_libraries_PACKAGE_ARCHITECTURE})
set(spec_regex *headers*)
elseif(check_file_applications_match)
set(check_file_match_expected_summary
.*${CPACK_RPM_PACKAGE_SUMMARY}.*)
set(check_file_match_expected_description
.*${CPACK_COMPONENT_APPLICATIONS_DESCRIPTION}.*)
set(check_file_match_expected_relocation_path Relocations :
${CPACK_PACKAGING_INSTALL_PREFIX}
${CPACK_PACKAGING_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR})
+set(check_file_match_expected_architecture Architecture:
${CPACK_RPM_headers_PACKAGE_ARCHITECTURE})
set(spec_regex *applications*)
elseif(check_file_Unspecified_match)
set(check_file_match_expected_summary
.*${CPACK_RPM_PACKAGE_SUMMARY}.*)
set(check_file_match_expected_description .*DESCRIPTION.*)
set(check_file_match_expected_relocation_path Relocations :
${CPACK_PACKAGING_INSTALL_PREFIX}
${CPACK_PACKAGING_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR})
+set(check_file_match_expected_architecture Architecture:
${CPACK_RPM_Unspecified_PACKAGE_ARCHITECTURE})
set(spec_regex *Unspecified*)
else()
message(FATAL_ERROR error: unexpected rpm package '${check_file}')
@@ -204,6 +208,10 @@ if(CPackGen MATCHES RPM)
message(FATAL_ERROR error: '${check_file}' rpm package relocation
path does not match expected value - regex
'${check_file_match_expected_relocation_path}'; RPM output:
'${check_file_content}'; generated spec file: '${spec_file_content}')
endif()
+ string(REGEX MATCH ${check_file_match_expected_architecture}
check_file_match_architecture ${check_file_content})
+ if (NOT check_file_match_architecture)
+ message(FATAL_ERROR error: '${check_file}' Architecture does not
match expected value - '${check_file_match_expected_architecture}'; RPM output:
'${check_file_content}'; generated spec file: '${spec_file_content}')
+ endif()
endforeach()
elseif(${CPackComponentWay} STREQUAL IgnoreGroup)
endif()
--
2.2.2
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
[cmake-developers] [PATCH 0/3] CPACK_RPM_PACKAGE_ARCHITECTURE
This patch series extends CPackRPM to support cross-built rpms Previously only native and noarch rpms were possible. Other architecture choices resulted in an error from rpmbuild. Also included at no extra charge, is component support through CPACK_RPM_component_PACKAGE_ARCHITECTURE, and unit tests for component architecture. Improvements suggested by Rolf Eike Beer: Drop WORKING_DIRECTORY and add OUTPUT_STRIP_TRAILING_WHITESPACE to uname command. Improvements suggested by Domen Vrankar: Add component support Add unit tests Joshua A Clayton (3): CPackRPM: Fix CPACK_RPM_PACKAGE_ARCHITECTURE CPackRPM: Support rpm architecture in components Tests: CpackRPM test component architecture Modules/CPackRPM.cmake | 33 ++ .../MyLibCPackConfig-IgnoreGroup.cmake.in | 6 .../RunCPackVerifyResult.cmake | 8 ++ 3 files changed, 41 insertions(+), 6 deletions(-) -- 2.2.2 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 2/3] CPackRPM: Support rpm architecture in components
CPACK_RPM_component_PACKAGE_ARCHITECTURE variable allows
the same project to support packages of different architectures
including noarch, native and foreign architectures.
---
Modules/CPackRPM.cmake | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 5135893..485c586 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -51,6 +51,7 @@
# * Default : CPACK_PACKAGE_VERSION
#
# .. variable:: CPACK_RPM_PACKAGE_ARCHITECTURE
+# CPACK_RPM_component_PACKAGE_ARCHITECTURE
#
# The RPM package architecture.
#
@@ -629,6 +630,16 @@ else()
message(CPackRPM:Debug: using user-specified build arch =
${CPACK_RPM_PACKAGE_ARCHITECTURE})
endif()
endif()
+#prefer component architecture
+unset(CPACK_RPM_PACKAGE_ARCHITECTURE_)
+if(CPACK_RPM_PACKAGE_COMPONENT)
+ if(CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_ARCHITECTURE)
+set(CPACK_RPM_PACKAGE_ARCHITECTURE_
${CPACK_RPM_${CPACK_RPM_PACKAGE_COMPONENT}_PACKAGE_ARCHITECTURE})
+if(CPACK_RPM_PACKAGE_DEBUG)
+ message(CPackRPM:Debug: using component build arch =
${CPACK_RPM_PACKAGE_ARCHITECTURE})
+endif()
+ endif()
+endif()
if (NOT CPACK_RPM_PACKAGE_ARCHITECTURE_)
set(CPACK_RPM_PACKAGE_ARCHITECTURE_ ${CPACK_RPM_PACKAGE_ARCHITECTURE})
endif()
--
2.2.2
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015411]: Toolset is not updated/loaded correctly in CMake GUI
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15411 == Reported By:Bryn Lloyd Assigned To: == Project:CMake Issue ID: 15411 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-02-19 03:41 EST Last Modified: 2015-02-19 03:41 EST == Summary:Toolset is not updated/loaded correctly in CMake GUI Description: Switching projects (build dirs) using different toolset in CMake GUI changes the toolset of the second project. Steps to Reproduce: We use the CMAKE_GENERATOR_TOOLSET option (or -T from command line). For one project we use the intel compiler toolset with a Visual Studio 2012 generator, for others we don't specify the toolset. When we switch from the project WITH an intel compiler toolset to another project in the CMake GUI, e.g. by selecting a different build folder, the second project suddenly also uses the intel compiler toolset. It seems like CMake GUI has some global variable which is not updated when loading a different project. == Issue History Date ModifiedUsername FieldChange == 2015-02-19 03:41 Bryn Lloyd New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 19 Feb 2015, at 18:52, Brad King brad.k...@kitware.com wrote: On 02/19/2015 11:54 AM, Raffi Enficiaud wrote: On the system I am working, matlab in the PATH is a symlink with r x permissions [snip] Is there any internal in the find_program to check what conditions are not met? What are the permissions of the underlying file after resolving the link? The find_program command wants r permission, and it always unwraps symlinks. If I continue the chain: renficiaud@madeira3:~$ ls -al /etc/alternatives/matlab lrwxrwxrwx 1 root root 43 Oct 20 15:32 /etc/alternatives/matlab - /is/software/matlab/linux/R2014a/bin/matlab renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab -r-xr-xr-x 1 stark is 55331 Dec 27 2013 /is/software/matlab/linux/R2014a/bin/matlab r permission are definitively there and the user is allowed to run this command. BTW, I cannot see in the documentation that find_program unwraps symlinks. By myself, I explained the observed behaviour as find_program being blind to symlinks. you propose to merge the variables MATLAB_USER_ROOT and Matlab_ROOT_DIR, is that correct? Yes. Furthermore, if we can always compute the other information from that value then as little of it should be cached as possible. Ok, will do then. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Please find attached the merge of the two previous patches, rebased on 5dae6cf.
Thanks,
Raffi Enficiaud
0001-Adding-R2014a.patch
Description: Binary data
On 19 Feb 2015, at 12:49, Raffi Enficiaud raffi.enfici...@free.fr wrote:
Dear Brad,
Apparently there are some issues when things are running with the dashboard,
which I did not observed yesterday.
Those issues are related to the space in the test folder in the dashboard,
which I did not see on my local computer.
The attached patch (based on 5dae6cf) should solve those issues (tested only
in the dashboard folder of the ubuntu version).
0001-Fixing-problems-related-to-spaces-in-directory-names.patch
Thanks,
Raffi
On 18 Feb 2015, at 23:11, Raffi Enficiaud raffi.enfici...@free.fr wrote:
Please find attached the patch addressing the issues + some others, rebased
against 5dae6cf.
I tested it on the 3 target platforms.
patch.diff
On 18 Feb 2015, at 15:13, Brad King brad.k...@kitware.com wrote:
On 02/17/2015 07:28 PM, Raffi Enficiaud wrote:
The tests were failing because of the following modification:
- matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
+ matlab_get_version_from_matlab_run(${Matlab_MAIN_PROGRAM}
matlab_list_of_all_versions)
Apparently the quotes here are interpreted as part of the binary name,
which prevents the proper call to matlab using the execute_process
function.
That should not be possible. The quotes are needed in case the variable
value is an empty string. They will not be treated as part of the value
passed to the function argument.
I restored the quotes. Maybe I experienced a caching issue: I run ctest with
FindMatlab regex, and from time to time the cache is messed while I am
working and I do not clean the folders systematically.
I kept the symlink resolution, but I narrowed the case those should be
resolved. I added a variable pointing to the (symlink resolved) location
of the binary from which the version is retrieved.
Yes, thanks.
I squashed the changes into 9d414ca2 and rebased again. Everything
so far is now in:
FindMatlab: Rewrite module and provide a usage API
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dae6cfc
and merged to 'next' for testing. Please base fixes for the below
on that.
Couple of questions:
- does the script of the dashboard clean the folders? Or I have to do that
manually? (cf caching issues above)
- is it the next branch that is tested on the nightly section of the
dashboard?
More comments:
Why do you need so many different find_program calls for matlab?
There should be exactly one for Matlab_MAIN_PROGRAM, and it does
not need to be guarded by if(NOT Matlab_MAIN_PROGRAM) because
find_program does that already. Any symlink resolution can be
done on the result.
I wanted to separate the parts in some kind of modules.
- The first part is supposed to output the Matlab_ROOT and nothing else, and
the other parts are relying on that. Finding a matlab_program is an
implementation detail, which is not cross platform. Yet, the method is
kind of robust to find a proper installation ROOT.
- The second part deals with the version, in case we have no other way than
from asking Matlab. Since at this point, we have a ROOT, either given by the
user or from the first part, we search for the matlab program using this
information alone. In case the user gave the ROOT but not the version, we
still have to find the program under this ROOT. In case the user gave
nothing, we have to find the ROOT and the version, the former maybe implying
a matlab_program search. Again, I think this is an implementation detail
that the second part should not rely on.
- The third part is the user facing matlab_program, that we find on demand.
I agree this can be optimized in terms of find_program calls, but I would
like to keep this structure for finding in the appropriate sequence all the
information needed by the module.
The symlink resolutions are made on the appropriate places now.
The get_filename_component(PROGRAM) mode is intended to take a
command line string and figure out which leading piece is an
existing program in case it is an unquoted path with spaces.
While it may be a bug that this can return a directory, there
should be no use case for this functionality in FindMatlab.
I did not understood that from the documentation (the program in filename
will be found in the system search path): I thought it was another way of
finding programs. I removed the corresponding lines.
# list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to
# reg does not work from cmake, curiously, as is. The command provides the
# desired result under the command line though.
# Fix: this is because /reg:64 should appended to the command, otherwise
# it gets on the 32 bits software key (curiously
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 08:39 AM, Raffi Enficiaud wrote:
Please find attached the merge of the two previous patches, rebased on
5dae6cf.
Applied, thanks:
FindMatlab: Further revisions
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1416d214
Those issues are related to the space in the test folder in the dashboard
Quoting of arguments in the cmake language:
http://www.cmake.org/cmake/help/v3.2/manual/cmake-language.7.html#command-arguments
is not necessary to deal with spaces that are not literally written in
the argument. Separation of unquoted arguments after variable evaluation
only happens on ;. However, any unnecessary quoting you added also
won't hurt anything and makes it easier to read anyway.
Returning to a previous comment:
On 02/18/2015 09:13 AM, Brad King wrote:
Why do you need so many different find_program calls for matlab?
There should be exactly one for Matlab_MAIN_PROGRAM
I still see four places that try to find matlab, quoted below.
It looks like you're trying to make Matlab_MAIN_PROGRAM defined
if the MAIN_PROGRAM component was requested.
find_program(
_matlab_main_tmp
NAMES matlab)
if(NOT _matlab_main_tmp)
execute_process(
COMMAND which matlab
OUTPUT_VARIABLE _matlab_main_tmp
ERROR_VARIABLE _matlab_main_tmp_err)
# the output should be cleaned up
string(STRIP ${_matlab_main_tmp} _matlab_main_tmp)
endif()
If find_program doesn't find it, which won't have better luck.
if(Matlab_MAIN_PROGRAM)
set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM})
else()
find_program(
_matlab_main_tmp
matlab
PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
DOC Matlab main program
NO_DEFAULT_PATH
)
endif()
We should not risk finding the wrong matlab here. See below.
# todo cleanup with code above
if(NOT DEFINED Matlab_MAIN_PROGRAM)
find_program(
Matlab_MAIN_PROGRAM
matlab
PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
DOC Matlab main program
NO_DEFAULT_PATH
)
endif()
This looks like the component-specific search. If we are to present
a component-specific result variable name then it can simply be
populated from the one true location found.
If matlab is needed to compute information for other components
then finding it should not be optional. There should be a single
find_program(Matlab_EXECUTABLE ...)
whose result is cached and re-used everywhere that matlab is
needed. Separate symlink-resolving on it can be done when needed
but does not need to be cached.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 10:20 AM, Raffi Enficiaud wrote: If find_program doesn't find it, which won't have better luck. I tested that yesterday on a regular LTS14.04 server. find_program fails while which matlab does not. Please figure out why find_program fails so we can fix it rather than working around it with which. The find_program command searches the PATH just like which does. Is matlab one of those executables with x permission but not r permission? Finding the matlab program from time to time is for me an implementation detail Okay, I just wanted an explanation for why there are so many find_program calls for the same thing. If the design is better that way then so be it. However: Also the main functionality is not performance oriented. If I start trying to optimize all those calls, I would have complicated execution paths. Caching is not about performance. It is about giving the user the opportunity to set the result explicitly when the automatic determination gets an undesired result. There needs to be at least (and ideally exactly) one cache entry that stores the location of matlab. If the user sets it up front then great. If not then we should search and store the result there for the user to accept or edit later. Currently MATLAB_USER_ROOT allows the user to specify up front, but does not serve the second role. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Ok, I thought this was for the ctest program that accepts -j flag. I will do the change, I am running the build already with all the // flags removed. Thanks, Raffi On 19 Feb 2015, at 15:17, Brad King brad.k...@kitware.com wrote: On 02/19/2015 06:49 AM, Raffi Enficiaud wrote: Apparently there are some issues when things are running with the dashboard For the Visual Studio build on your Windows machine you have: set(CTEST_BUILD_FLAGS -j4) which is not a valid msbuild flag. For that you could use set(CTEST_BUILD_FLAGS -m4) instead. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 19 Feb 2015, at 14:53, Brad King brad.k...@kitware.com wrote:
On 02/19/2015 08:39 AM, Raffi Enficiaud wrote:
Please find attached the merge of the two previous patches, rebased on
5dae6cf.
Applied, thanks:
FindMatlab: Further revisions
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1416d214
Thanks.
Those issues are related to the space in the test folder in the dashboard
Quoting of arguments in the cmake language:
http://www.cmake.org/cmake/help/v3.2/manual/cmake-language.7.html#command-arguments
is not necessary to deal with spaces that are not literally written in
the argument. Separation of unquoted arguments after variable evaluation
only happens on ;. However, any unnecessary quoting you added also
won't hurt anything and makes it easier to read anyway.
Good then. Matlab supports not very well spaces in the log file name, I suppose
that if I do
execute_process(COMMAND matlab -logfile some path with spaces)
this is correctly escaped by cmake.
Returning to a previous comment:
On 02/18/2015 09:13 AM, Brad King wrote:
Why do you need so many different find_program calls for matlab?
There should be exactly one for Matlab_MAIN_PROGRAM
I still see four places that try to find matlab, quoted below.
It looks like you're trying to make Matlab_MAIN_PROGRAM defined
if the MAIN_PROGRAM component was requested.
Relates to my previous answer on this topic.
find_program(
_matlab_main_tmp
NAMES matlab)
if(NOT _matlab_main_tmp)
execute_process(
COMMAND which matlab
OUTPUT_VARIABLE _matlab_main_tmp
ERROR_VARIABLE _matlab_main_tmp_err)
# the output should be cleaned up
string(STRIP ${_matlab_main_tmp} _matlab_main_tmp)
endif()
If find_program doesn't find it, which won't have better luck.
Which is also what I thought but this is factually incorrect. I tested that
yesterday on a regular LTS14.04 server. find_program fails while which matlab
does not.
if(Matlab_MAIN_PROGRAM)
set(_matlab_main_tmp ${Matlab_MAIN_PROGRAM})
else()
find_program(
_matlab_main_tmp
matlab
PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
DOC Matlab main program
NO_DEFAULT_PATH
)
endif()
We should not risk finding the wrong matlab here. See below.
# todo cleanup with code above
if(NOT DEFINED Matlab_MAIN_PROGRAM)
find_program(
Matlab_MAIN_PROGRAM
matlab
PATHS ${Matlab_ROOT_DIR} ${Matlab_ROOT_DIR}/bin
DOC Matlab main program
NO_DEFAULT_PATH
)
endif()
This looks like the component-specific search. If we are to present
a component-specific result variable name then it can simply be
populated from the one true location found.
In the code just above, the if() condition is not needed anymore since now
there is no aliasing with the previous searches. I'll fix that.
On Windows, we have the Matlab_ROOT and the version from the registry, so we
need to run find_program there. On OSX, if the previous find_program or which
matlab did not result in anything relevant, we parse the
/Application/MATLAB_xxx folders so we end up with a root and a version without
a main_program, so the find_program above is also needed.
If matlab is needed to compute information for other components
then finding it should not be optional. There should be a single
find_program(Matlab_EXECUTABLE ...)
whose result is cached and re-used everywhere that matlab is
needed. Separate symlink-resolving on it can be done when needed
but does not need to be cached.
I agree with that, but this behaviour is not consistent across every platforms.
My preference goes to the kind of modular approach currently implemented in the
module, which is:
1- find all possible matlab roots with the tools provided by the system, or
just stick to the user input
2- for each or one of them, find the version if information is lacking
3- return the one that fits best to the find_matlab options
Finding the matlab program from time to time is for me an implementation
detail: examples
- if the user give the Matlab_ROOT, the version is lacking, I then need to find
matlab in the second step.
- if the user gave no input, I need to find Matlab in the first step,
conditionally on the platform, to extract Matlab_ROOT (and not to find matlab
itself). I then run the find_matlab in the second step conditionally on the
platform again. In the third step, I gather all the information I have so far,
which is the intersection for all platforms: MatlabROOT and MatlabVERSION.
- on win32, if there is not user defined Matlab_ROOT, we have the root and
version from the registry, there is only the last component oriented
find_program running, only if required by the user.
Also the main functionality is not performance oriented. Caching is in fact an
undesirable side-effect for what I want to achieve. While finding matlab is
certainly not optimal,
Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI
On 02/17/2015 01:46 PM, Brad King wrote: On 02/17/2015 01:43 PM, Robert Dailey wrote: Of course right now only Visual Studio and XCode support the toolset parameter Correct. Furthermore it is supported only for VS = 10. In response to this issue: http://www.cmake.org/Bug/view.php?id=15411 I've made this change: cmake-gui: Reset generator platform and toolset on configure (#15411) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ade687d Please account for that while developing your changes. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 19 Feb 2015, at 22:24, Brad King brad.k...@kitware.com wrote:
On 02/19/2015 04:15 PM, Raffi Enficiaud wrote:
renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab
-r-xr-xr-x 1 stark is 55331 Dec 27 2013
/is/software/matlab/linux/R2014a/bin/matlab
r permission are definitively there and the user is allowed to run this
command.
Hmm. See if you can reproduce it with something simple like:
[snip]
I cannot reproduce with this simple example. However, on next, I did that (line
990):
find_program(
_matlab_main_tmp
NAMES matlab)
message(FATAL_ERROR is find matlab correct? ${_matlab_main_tmp})
The error message is
CMake Error at /is/ps2/renficiaud/Code/CMake/Modules/FindMatlab.cmake:993
(message):
is find matlab correct?
Call Stack (most recent call first):
CMakeLists.txt:11 (find_package)
Then I did that:
find_program(
matlab_main_tmp
NAMES matlab)
message(FATAL_ERROR is find matlab correct? ${matlab_main_tmp})
and the error message is
CMake Error at /is/ps2/renficiaud/Code/CMake/Modules/FindMatlab.cmake:993
(message):
is find matlab correct? /usr/bin/matlab
Call Stack (most recent call first):
CMakeLists.txt:11 (find_package)
The functionality works then, there is something else with the variable itself.
Some lines before I uses the same variable name
set(_matlab_main_tmp )
I just unset this variable before the call to the find_program, and now it
works good. Basically the variable is not overwritten, maybe because another
one is created in the cache?
Any hint? Known behaviour?
I'll do the fix and remove the which matlab then (so we dropped the # of
find matlab from 4 to 2 in one day).
Best,
Raffi
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 04:15 PM, Raffi Enficiaud wrote:
renficiaud@madeira3:~$ ls -al /is/software/matlab/linux/R2014a/bin/matlab
-r-xr-xr-x 1 stark is 55331 Dec 27 2013
/is/software/matlab/linux/R2014a/bin/matlab
r permission are definitively there and the user is allowed to run this
command.
Hmm. See if you can reproduce it with something simple like:
$ cat test.cmake
find_program(MATLAB NAMES matlab)
message(MATLAB=${MATLAB})
$ cmake -P test.cmake
Then build your own CMake with -DCMAKE_BUILD_TYPE=Debug and run it in
a debugger to track down what goes wrong. Set a breakpoint on
cmsys::SystemTools::FileExists to step through the low level checks.
BTW, I cannot see in the documentation that find_program unwraps symlinks.
I meant that when checking for existence and permissions it uses
something equivalent to stat as against lstat. A broken symlink
is not considered to exist. It certainly doesn't resolve symlinks
in the returned path.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 06:49 AM, Raffi Enficiaud wrote: Apparently there are some issues when things are running with the dashboard For the Visual Studio build on your Windows machine you have: set(CTEST_BUILD_FLAGS -j4) which is not a valid msbuild flag. For that you could use set(CTEST_BUILD_FLAGS -m4) instead. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 19 Feb 2015, at 16:48, Brad King brad.k...@kitware.com wrote: On 02/19/2015 10:20 AM, Raffi Enficiaud wrote: If find_program doesn't find it, which won't have better luck. I tested that yesterday on a regular LTS14.04 server. find_program fails while which matlab does not. Please figure out why find_program fails so we can fix it rather than working around it with which. The find_program command searches the PATH just like which does. Is matlab one of those executables with x permission but not r permission? On the system I am working, matlab in the PATH is a symlink with r x permissions renficiaud@madeira3:~/Code/CMake$ which matlab /usr/bin/matlab renficiaud@madeira3:~/Code/CMake$ ls -al /usr/bin/matlab lrwxrwxrwx 1 root root 24 May 15 2013 /usr/bin/matlab - /etc/alternatives/matlab renficiaud@madeira3:~/Code/CMake$ ls -al /etc/alternatives/matlab lrwxrwxrwx 1 root root 43 Oct 20 15:32 /etc/alternatives/matlab - /is/software/matlab/linux/R2014a/bin/matlab renficiaud@madeira3:~/Code/CMake$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games Is there any internal in the find_program to check what conditions are not met? Finding the matlab program from time to time is for me an implementation detail Okay, I just wanted an explanation for why there are so many find_program calls for the same thing. If the design is better that way then so be it. However: Also the main functionality is not performance oriented. If I start trying to optimize all those calls, I would have complicated execution paths. Caching is not about performance. It is about giving the user the opportunity to set the result explicitly when the automatic determination gets an undesired result. There needs to be at least (and ideally exactly) one cache entry that stores the location of matlab. If the user sets it up front then great. If not then we should search and store the result there for the user to accept or edit later. Currently MATLAB_USER_ROOT allows the user to specify up front, but does not serve the second role. If I understand correctly, you propose to merge the variables MATLAB_USER_ROOT and Matlab_ROOT_DIR, is that correct? Or just drop Matlab_ROOT_DIR from the user view? Best, Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/19/2015 11:54 AM, Raffi Enficiaud wrote: On the system I am working, matlab in the PATH is a symlink with r x permissions [snip] Is there any internal in the find_program to check what conditions are not met? What are the permissions of the underlying file after resolving the link? The find_program command wants r permission, and it always unwraps symlinks. you propose to merge the variables MATLAB_USER_ROOT and Matlab_ROOT_DIR, is that correct? Yes. Furthermore, if we can always compute the other information from that value then as little of it should be cached as possible. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support
Great, thanks. However, we really need to have the cmake_common.cmake script used to drive it The nightly build that I use does use the cmake_common.cmake script to grab the latest code, build, test it, etc. Here's what my nightly build results look like: https://open.cdash.org/buildSummary.php?buildid=3701008. Any tests depending on local system configuration need to have an option to explicitly enable them on such systems. See the existing CMake_TEST_FindJsonCpp option for example. Just put your new test(s) inside a condition on a CMake_TEST_GreenHillsMULTI variable. Then add to your dashboard script:: set(dashboard_cache CMake_TEST_GreenHillsMULTI:BOOL=ON ) before including cmake_common.cmake and the tests will be enabled once they are in the repo. I made that small change in the attached patch. I ran another experimental build in debug. Here are those results: https://open.cdash.org/buildSummary.php?buildid=3701457. I expected the CMakeOnly.MajorVersionSelection-PythonInterp_2 to fail because I have the Python 3.3 executable in my path. But I still get the CMake.GetPrerequisites test timing out. Also, I haven't debugged the warnings in the Build row yet. This suit of tests was done using a script based on the autogenerated CTestScript.cmake script. Geoffrey Viola SOFTWARE ENGINEER asirobots.com -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, February 17, 2015 9:02 AM To: Geoffrey Viola Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support On 02/17/2015 10:47 AM, Geoffrey Viola wrote: I submitted a test report with all the tests passing. https://open.cdash.org/buildSummary.php?buildid=3698090. Great, thanks. However, we really need to have the cmake_common.cmake script used to drive it. What I was asking in my previous response was for you to get a normal nightly testing dashboard submission configured and working independent of your changes. For that using the common script with ctest_update is okay. I'm not sure how to handle cases where the user wants to run all the test and expects all to pass, but does not have Green Hills installed. Any tests depending on local system configuration need to have an option to explicitly enable them on such systems. See the existing CMake_TEST_FindJsonCpp option for example. Just put your new test(s) inside a condition on a CMake_TEST_GreenHillsMULTI variable. Then add to your dashboard script:: set(dashboard_cache CMake_TEST_GreenHillsMULTI:BOOL=ON ) before including cmake_common.cmake and the tests will be enabled once they are in the repo. Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 0001-Added-some-support-for-a-Green-Hills-MULTI.patch Description: 0001-Added-some-support-for-a-Green-Hills-MULTI.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
