[cmake-developers] Minor regression in --version results for CMake 2.8.12.1 (A FALSE ALARM)

[Alan W. Irwin]

On 2013-12-04 19:10-0800 Alan W. Irwin wrote:

> [...]This (very simple) issue is
>
> cmake --version
>
> emits the string "cmake version 2.8.12" rather than the expected
> "cmake version 2.8.12.1"
>
> This is a regression from previous behaviour.  For example, here
> are the results for cmake-2.8.11.2
>
> "cmake version 2.8.11.2"
>

Sorry, this turned out to be a false alarm. Despite "which cmake"
telling me I was using cmake-2.8.12.1, I was actually using
cmake-2.8.12 due to a stale bash cache of the executable locations.
After I got rid of the stale cache, bash finally found the desired
cmake-2.8.12.1 version which does produce the correct "cmake version
2.8.12.1" version string.

So that is the short story, and nobody needs to read further to the
longer and off-topic bash and hash story below unless you are
interested in how you can inadvertently create such a stale bash cache
for executable locations and how to avoid that situation.

<OFF TOPIC> 
The situation was I had been using cmake-2.8.12 so bash
put that in the cache of executable locations to avoid the PATH lookup
(which is a non-POSIX bash extension which reduces latency, but the
"which" command only gives results that are appropriate for
POSIX-conformant shells).  So because that cache was stale after I
had built cmake-2.8.12.1 the result of "cmake --version" was still
"cmake version 2.8.12" (just as expected if you knew about the stale
cache result).  The algorithm bash uses for renewing the cache is
so effective you normally don't run into stale cache issues with bash,
and, in fact, I was unaware that issue was even possible with bash
despite many years experience with bash.

What happened today was I built cmake-2.8.12.1 and installed it high
on the existing PATH without changing that PATH. So the cache was
stale and still pointed to 2.8.12 despite the "which cmake" result
(pointing to cmake-2.8.12.1) which gave me the (false) confidence to
report what turned out to be a false alarm above. Later when I changed
the PATH, it turned out that bash took that as a signal to empty the
cache of the stale results, and after that cmake-2.8.12.1 was found
because it was higher on the PATH than 2.8.12. And that version
definitely produces the correct version string, "cmake version 2.8.12.1".

The number one thing I leaned today is do not trust "which" results
unless you have emptied or renewed the cache.  Furthermore, the bash
builtin "hash" command can be used to manipulate the cache.  (Look at
the bash man page for documentation of the "hash" builtin"). You can
renew the cache table entry for cmake by executing "hash cmake".  Or
you can completely empty the cache (forcing all entries to be renewed
whenever commands are run) using "hash -r".  Or as I found out above
by experiment you can just change the PATH to empty the cache, and it
is quite possible that bash has other triggers for emptying the cache
as well.

In sum, I learned quite a lot today that I never knew before about the
bash cache for command locations and how to manipulate that cache with
the "hash" builtin for bash.  If you want to learn even more, then I
recommend looking at <http://bradconte.com/bash-path-hashing>.
</OFF TOPIC>

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
__________________________