On 2014-03-07 03:28-0800 phil rosenberg wrote:
> My main issue with CMake is that I don't really know how the
(I) execution flow works, or how (II) scope works, or how it (III) interacts
with
existing or predefined variables. So modifying existing code is not to
bad, but when it comes to starting things from scratch or working
through multiple files I'm rather lost. As much as I would love to
learn, I feel like I have other priorities (both Plplot related and
not). However, if there are some tests you can do to guide things then
I am happy to keep working on this.
Hi Phil:
In the free software world autotools and cmake are the two main
choices to use for build systems. Once KDE shifted from the former to
the latter for well-publicized reasons in 2006, many other projects
such as PLplot did so as well, and from the large and still growing
activity on the CMake mailing lists 8 years later, that trend just
keeps getting stronger and stronger. So my judgement is it would be
worthwhile for you to learn CMake skills not only because it empowers
you as a PLplot developer, but also because it is a general developer
skill that should help you with the large and growing number of
software projects that currently have CMake-based build systems.
So assuming that reasoning appeals to you (or anyone else here) let me
give some answers to the important questions you have stated above.
Note, you should check out everything I say using the principal CMake
documentation method which is simply to run "cmake --help-full >&
cmake_documentation_file" and then search through that generated file
for the CMake commands I mention.
(I) execution flow
The include function is one important means of executing CMake logic
that is specified in a file. There are two ways (file and module) to
run include. The module method is the one that is used most and
depends on the CMAKE_MODULE_PATH list to search directories for the
specified module. So our principal CMakeLists.txt file uses
set(CMAKE_MODULE_PATH
${PROJECT_SOURCE_DIR}/cmake/modules
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake-2.8
)
We then follow with
include(plplot)
which then runs all the CMake code in cmake/modules/plplot.cmake which
in turn includes lots of other CMake logic in that directory such as
drivers.cmake ==> wxwidgets.cmake.
Another important means of executing CMake logic is the
find_package command which is also affected by CMAKE_MODULE_PATH.
So when wxwidgets.cmake executes
find_package(wxWidgets COMPONENTS base core QUIET)
with the CMAKE_MODULE_PATH set as above, the logic in
cmake/modules/FindwxWidgets.cmake is executed rather the
logic in the CMake system version of that find module.
(II) scope
All the CMake logic mentioned so far shares the same scope which is
the scope of the CMakeLists.txt file which started the chain of
include and find_package commands. This is the most general scope
possible within the PLplot build system since that is the top-level
CMakeLists.txt file for the project. This scope is perpetrated
"downward" to other CMakeLists.txt files that are accessed via the
add_subdirectory command. But any changes made to ordinary
(non-cached) variables in those subdirectory CMakeLists.txt files are
never propagated upward which is the principal way that scope is limited
under CMake.
(III) variables
For documentation of the two kinds (cached and non-cached) of
variables under CMake, please look carefully at the documentation of
the set command. Generally, non-cached variables are used by CMake
logic with the important exception of storing the results of expensive
operations such as find commands. Such cached results allow subsequent
runs of cmake to skip the expensive operations altogether in the
interest of speed. But sometimes the cache (which is stored in the
CMakeCache.txt file in the top-level build tree) may contain bad or
stale results as the result of an error. So that is why I emphasize
when debugging a build-system issue that it is good to run cmake with
an initially empty build tree every time you want to test some change
you make to the build system.
Note you can beat the scoping rules of non-cached variables by using
cached variables, but that is never a good idea. Instead, if you want
some non-cached variable to be globally available, set it in the
top-level CMakeLists.txt file or else in the many files in
cmake/modules that are included from that top-level CMakeLists.txt
file.
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
__________________________
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
