[cmake-developers] Advantages and disadvantages in blowing away CMAKE_MODULE_PATH
On 2017-05-25 15:01-0400 Chuck Atkins wrote: 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. Hi Chuck: Thanks for describing the use case you had in mind as a background to your remarks concerning why you thought blowing away CMAKE_MODULE_PATH was not ideal. However, although the CMake software project itself does integrate software from other projects into the CMake project, and I assume there are also other well-known examples, I suspect that use case is uncommon in general (at least on Unix systems where the culture positively encourages keeping every software package as independent as possible from every other software package.) Furthermore, projects blowing away CMAKE_MODULE_PATH by setting that variable in their top-level CMakeLists.txt file do have the one advantage I alluded to which is this approach precludes users of such projects from using that variable to point to an inappropriate set of find modules. And, as you mentioned, blowing away the variable simply means that projects which integrate your software have one additional one-line change to make. So it appears there is a relatively small advantage to blowing away CMAKE_MODULE_PATH and a relatively small disadvantage as well. On balance I think I will continue with our present "blow-away" approach, but this is a decision developers of each project need to make for themselves. 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
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&D 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&D 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&D 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
