[cmake-developers] Advantages and disadvantages in blowing away CMAKE_MODULE_PATH

[Alan W. Irwin]

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
__________________________