Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
>
> Hi Chuck (off list):
>
Hi Alan (on list)
> but the one above I completely missed.
...
> with the hint above I should be able to figure out
> all those remaining issues on my own
Excellent! Glad to hear it. Inconsistent path quoting is a common pitfal
when writing portable CMake code. It bites all of us at one point or
another, even Brad sometimes. Glad I could help.
> Or even better, don't blow away the current module path, jsut append to
>>> the front:
>>> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
>>>
>>
> What is the use case you had in mind for not blowing away
> CMAKE_MODULE_PATH? Does CMake itself sometimes set CMAKE_MODULE_PATH
> so blowing away this variable by setting it in the top-level
> CMakeLists.txt file (something that is done in all the CMake-based
> build systems I have helped to implement) could cause problems?
The typical use case is when your package is being used as a third party
library by somebody else. There are many different ways that could be done
but for small dependencies, a typical approach is to just place the code in
a subdirectory and add it to an existing build with add_subdirectory. In
this case, the calling project has set up the environment in a particular
way and your forcibly throwing it away. There's other use cases for it but
it's typically good practice to make yourself work within an existing
environment rather than ignore the environment and create your own unless
you have a specific reason (other than I don't know what they're going to
do)
I wouldn't want to allow such freedom to users of software packages I am
> associated with since it implies a significant increase (more things
> that could possibly go wrong) in the support burden for each such
> project.
It's certainly up to you since it's your code but if you're distributing
source then somebody will just change it anyway if that's their use case.
Using the insert instead of set allows both uses cases; i.e. as a
standalone library or a third party library included by a larger CMake
project, so why limit it.
- Chuck
--
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] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
In addition to that in the Main CMakeLists.txt, make a similar change in
CMakeTestAdaCompiler.cmake. Replace:
set(CMAKE_MODULE_PATH ${CMAKE_Ada_MODULES})
with:
list(INSERT CMAKE_MODULE_PATH 0 \"${CMAKE_Ada_MODULES}\")
The additional quoting here is because it's inside a file(WRITE ...)
command. With both of those changes, I get:
source: ~/tmp/test_ada source
binary: ~/tmp/test_ada build
output:
[chuck.atkins@hal9000 test_ada build]$ cmake ../test_ada\ source
-- The C compiler identification is GNU 6.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_Ada_COMPILER_ID = GNU
-- Check for working /usr/bin/gnatmake compiler:
-- Check for working /usr/bin/gnatmake compiler: -- works
-- CMAKE_Ada_COMPILER = /usr/bin/gnatgcc
-- GNAT_MAJOR_VERSION = 6
-- GNAT_VERSION = 6.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/
khq.kitware.com/chuck.atkins/tmp/test_ada build
[chuck.atkins@hal9000 test_ada build]$
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Thu, May 25, 2017 at 12:00 PM, Chuck Atkins
wrote:
> Hi Alan,
>
> You're missing quotes so when CMake expands CMAKE_SOURCE_DIR then the
> space in the filename is interpreted as a list separator, no different than:
> set(my_list foo bar)
> What you want instead is:
> set(my_list "foo bar")
>
> Change:
> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
> To:
> set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")
>
> Or even better, don't blow away the current module path, jut append to the
> front:
> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
>
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Mon, May 22, 2017 at 3:58 PM, Alan W. Irwin
> wrote:
>
>> So my guess is the measures that have been used so that a blank in the
>>> fullpath name works fine for CMake language support files that are
>>> installed by CMake have not been extended to the case where
>>> CMAKE_MODULE_PATH must be used to find the language support files.
>>>
>>
>> I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
>> to find the find modules we have implemented. That use case works
>> without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
>> So such a blank only appears to be an issue when CMAKE_MODULE_PATH
>> is used to find language support files.
>>
>> Alan
>>
>> __
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __
>>
>> Linux-powered Science
>> __
>> --
>>
>> 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
>>
>
>
--
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] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
Hi Alan,
You're missing quotes so when CMake expands CMAKE_SOURCE_DIR then the space
in the filename is interpreted as a list separator, no different than:
set(my_list foo bar)
What you want instead is:
set(my_list "foo bar")
Change:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
To:
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")
Or even better, don't blow away the current module path, jut append to the
front:
list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Mon, May 22, 2017 at 3:58 PM, Alan W. Irwin
wrote:
> So my guess is the measures that have been used so that a blank in the
>> fullpath name works fine for CMake language support files that are
>> installed by CMake have not been extended to the case where
>> CMAKE_MODULE_PATH must be used to find the language support files.
>>
>
> I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
> to find the find modules we have implemented. That use case works
> without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
> So such a blank only appears to be an issue when CMAKE_MODULE_PATH
> is used to find language support files.
>
> Alan
>
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
--
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] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
So my guess is the measures that have been used so that a blank in the fullpath name works fine for CMake language support files that are installed by CMake have not been extended to the case where CMAKE_MODULE_PATH must be used to find the language support files. I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH to find the find modules we have implemented. That use case works without issues when CMAKE_MODULE_PATH has a blank in the full pathname. So such a blank only appears to be an issue when CMAKE_MODULE_PATH is used to find language support files. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
I have been systematically testing PLplot builds for any issues with blanks in the prefix of the source, build, and install trees, and generally all is well under these test conditions. However, we do have two remaining issues which are that our (external) language support for both Ada and D fails if there is a blank in the source tree prefix. Our Ada language support comes with a simple "Hello, world" test project to test for language support issues for that language, and I have attached a tarball of that simple project so you can easily replicate this "blank in source tree" issue for yourself for at least that language. This test project works fine if the tarball is unpacked in a location without blanks in the full pathname, but fails when there is a blank in that unpacked pathname. The initial error message in that latter case is CMake Error: Could not find cmake module file: CMakeAdaInformation.cmake Such external language support (e.g., in this Ada case) must necessarily set CMAKE_MODULE_PATH to help CMake find the external language support files such as CMakeAdaInformation.cmake, and that full pathname necessarily contains a blank when the tarball is unpacked in a location with a blank in the full pathname. I thought the trouble might be that CMake just did not accept blanks in the full pathname of _any_ language support files, but I tested that case (by moving a previous CMake install location to one with a blank in its full pathname), but a simple project consisting of # Test C language support cmake_minimum_required(VERSION 3.8.1 FATAL_ERROR) project(test_c C) had no issues under those conditions, i.e., with the C language support files in the /share/share/cmake-3.8/Modules/ directory tree. So my guess is the measures that have been used so that a blank in the fullpath name works fine for CMake language support files that are installed by CMake have not been extended to the case where CMAKE_MODULE_PATH must be used to find the language support files. If that is the issue, a fix would be appreciated. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ test_ada.tar.gz Description: Simple test case for Ada language support -- 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
