Store both the as-written and lower-case command names and use
the latter to avoid case-insensitive string comparisons.
With this I obtain 2-6% speed increase (on Windows) for the configure
step with no significant changes in memory usage. A case-insensitive
comparison is a lot slower than just calling `==` because the operator
will use things like memcmp, so prefer the latter.
The `cmSystemTools::LowerCase` function allocates a new string each time
it is called, so before this change we were allocating in:
* cmMakefile::Configure two times for each function
(to look for `cmake_minimum_required` and `project`)
* cmMakefile::ExecuteCommand twice by function by calling
cmState::GetCommand and copying the name
Now we are only allocating once by function instead of four.
The plural-named non-cached result variable is needed to follow our
module conventions documented in `cmake-developer(7)`. The variable is
also used to populate our ``BZip2::BZip2`` imported target include
directories, which was broken without this variable set.
Fixes: #18013
Similar to ECLIPSE_EXTRA_NATURES which can be used to add a third party
nature to the .project, this property offers the possibility to inject
third party contents into the .cproject.
An example of where this is useful is MCUXpresso. This is an IDE based
on Eclipse. Compiling through CMake generated Eclipse projects works
fine by using a custom toolchain. However, in order to be able to debug
using such a project, an extra storageModule specific to the target
board is needed in the cproject.
Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit 5357cfc4af0cbef4c78df5834ff0440cee3148d1 (master).
Upstream Shortlog
-----------------
Peter Wu (1):
898dc6b9 SystemTools: Fix GetLineFromStream to avoid libc++ bug on OS X 10.7
Versions of clang-format newer than 3.8 produce different output.
Our source code guide says that version 3.8 exactly must be used.
Update the comment in our `.clang-format` config file accordingly.
Add a check to our formatting script to verify the version.
Also update its tool search to look for the explicitly-named
3.8 variant first.
I have been hitting the Windows command-line limit when cross-compiling
static library (POCO) and having more than 8000 characters in the call
to "ar". Calculating exact limits here are tricky, since this particular
limit will only take into account object file strings, which is correct
for response files, but not for the archive rules (link.txt files),
since they also contain the call to "ar" and its arguments.
Also, there can be other additional arguments if "ar" tool is wrapped
into something else, so it is a good idea to leave more space than
trying to exactly fit the limit.
Since response files use half of the limit as a heuristic, we reproduce
it here for consistency.
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Fixes: #17943