If a Windows resource (.rc) source file is included in a STATIC library,
the VS "link" tool will process the compiled ".res" file and needs to know
the target architecture. Without it, we may get a LNK4068 warning and
possibly a LNK1112 error. Add /machine: to the default static library
flags to give the link tool the information it needs.
Since commit v3.3.0-rc1~62^2~5 (cmTarget: Store only cmListFileContext
for CMP0023 handling, 2015-05-18) a call to target_link_libraries on a
target that was defined in another (non-ancestor) directory crashes
because no execution context is left active. Fix this by getting the
execution context from the actual cmMakefile where the current
target_link_libraries call takes place. Test this by verifying that
such calls correctly produce an error diagnostic instead of crashing.
When writing export files, correctly encode property values that contain
characters special to the CMake language parser. We must ensure that
they parse correctly when loaded on the consuming side.
Reported-by: Dan Liew <dan@su-root.co.uk>
In commit v3.3.0-rc1~49^2~2 (cmake-gui: Add --install option to add
command-line tools on OS X, 2015-05-19) the option default was set to
/usr/bin because that is where the old command line install dialog
placed the symlinks. A better default is /usr/local/bin because it is
meant for locally installed software rather than Apple-installed tools.
Also, as of OS X El Capitan, special privileges are required even for
root to modify /usr/bin but not /usr/local/bin.
e7714235 Get the local generator from the GeneratorTarget.
5aa556be cmMakefileTargetGenerator: Require cmGeneratorTarget.
bb88668a cmNinjaGenerator: Require cmGeneratorTarget.
a3b210fd cmGeneratorTarget: Require a cmLocalGenerator to construct.
8ec60c67 cmGlobalGenerator: Create GeneratorTargets with a local generator.
dee197fe GHS: Use a cmGeneratorTarget in generator API.
b2b41b83 cmGeneratorTarget: Add accessor for cmLocalGenerator.
2e9333a1 C::B: Get the Makefile from the LocalGenerator, not vice-versa.
Since version 24, Emacs supports a generic mode called prog-mode. Like
all other modes it has its own mode-hook, prog-mode-hook. For Emacs
users it is common to provide all your generic programming-mode related
customizations in this mode-hook.
cmake-mode is definitely a programming-mode and should support calling
this hook. There are two ways to make that happen:
* Make your major-mode a derived-mode from prog-mode.
* Manually calling the hook upon mode-activation.
Implementing a derived mode may be the most proper thing to do, but that
may require quite a few structural changes. For now just call the hook
explicitly if it exists. This should cover much of what users need.
The Makefile is a configure-time concept, and the LocalGenerator
is a generate time concept. The LocalGenerator should not be available
from the Makefile.
820986ed cmLocalGenerator: Constify GetIncludeDirectories method.
b3e2e332 QtAutogen: Get the global generator from the Makefile.
61c0113c cmLocalUnixMakefileGenerator3: Remove unused method.
080489b8 cmMakefile: Use member directly instead of through method.
8bfaadfa cmMakefile: Move IsRoot API from cmLocalGenerator.
217c243d cmake: Update the current snapshot when Resetting.
eb05dcd6 cmLocalGenerator: Add IssueMessage method.
cfae7fa4 cmMakefile: Use cmOutputConverter instead of cmLocalGenerator.
ccf7760f cmOutputConverter: Constify API.
782657db cmListFileArgument: Remove FilePath member.
a863c59f cmMakefile: Use GetExecutionFileStack method.
076760a6 cmMakefile: Add filename context to ExpandArguments.
569f4785 cmFunctionCommand: Store the FilePath when creating the prototype.
f971ab04 cmMacroCommand: Store the FilePath when creating the prototype.
The fix in commit v3.2.3~3^2 (Fix assertion failure on unmatched foreach
in function, 2015-05-18) broke handling of unmatched non-loop blocks
because it assumed all function blockers removed during error unwinding
were for loops, essentially switching the set of mishandled cases.
The purpose of the loop block push/pop operations is to define a scope
matching the lifetime of the loop function blockers. Since our function
blockers already have the proper lifetime, simply move the push/pop
operations to their constructor/destructor.
Extend the RunCMake.Syntax test with a case covering this.