Currently it only adds the contents of the COMPILE_FLAGS target
property, but it can be extended to handle a new COMPILE_OPTIONS
generator expression enabled property.
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
Commit 08cb4fa4 (Process generator expressions in the
INCLUDE_DIRECTORIES property, 2012-09-18) contained an incorrect
assumption that CMAKE_BUILD_TYPE was set on the makefile for each
generated configuration in multi-config generators. Fix that by making
the GetIncludeDirectories API depend on the config.
This way we don't need to check the definitions from the Makefile when
generating later, and can more easily add generator expressions.
Duplication is not a problem as the definitions are de-duplicated before
generating.
There is no need to do so. Be consistent with include directories and
ensure uniqueness.
This requires changing the API of the cmLocalGenerator::AppendDefines
method, and changing the generators to match.
The test unfortunately can't test for uniqueness, but it at least verifies
that nothing gets lost.
Teach cmMakefile::AddCustomCommandToOutput to return the cmSourceFile
instance to which the custom command is attached. Use the return value
instead of separately adding a .rule extension and searching for the
source. Mark CMake-generated .rule files explicitly with a property
instead of trusting the file extension.
Since commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source
classification, 2012-03-19) the VS 10 generator uses the
cmGeneratorTarget source classification instead of directly getting the
list of source files from the target. This accidentally dropped the
CMakeLists.txt files from generated projects because they are added too
late for cmGeneratorTarget.
All generator-specific source files must be added to targets prior to
cmGeneratorTarget construction. Refactor addition of the CMakeLists.txt
files with CMake re-run custom commands to take place before normal
generation begins, and therefore early enough to be included in the
cmGeneratorTarget classification.
For now do not allow an OBJECT library to reference other object
libraries. Teach cmTarget::ComputeLinkImplementation to include the
languages of object libraries used by a target.
Treat OBJECT libraries as STATIC libraries. The VS project file format
provides no way to avoid running the librarian so hide the resulting
.lib away next to the object files as it should never be referenced.
The object files will be left behind for reference by other targets
later.
Implement cmGlobalGenerator::ComputeTargetObjects in the VS generator
to pre-compute all the object file names. Use the results during
generation instead of re-computing it later.
b28e7fa VS6: Avoid SBCS test on VS6 (#12189)
df19b9c VS6: Avoid _MBCS define when _SBCS is defined (#12189)
ba89e92 Visual Studio: Allow setting Single Byte Character Set (#12189)
Simplify cmLocalVisualStudioGenerator::ComputeObjectNameRequirements to
loop over the original vector of source files instead of recursively
traversing source groups just to find the same files. Drop from
cmVisualStudio10TargetGenerator::ComputeObjectNames temporary source
group calculation now that it is not needed for computing object names.
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
Move the Version member to the top cmLocalVisualStudioGenerator class
and set it consistently for instances created by all the global
generator versions. Use an enumeration type with values scaled by a
factor of 10 so we can handle VS 7.1 without out-of-order numbers.
VS 7.1 support for SuppressStartupBanner was broken by commit 25116a3c
(Fix CMAKE_VERBOSE_MAKEFILE for VS10 vcxproj files, 2011-10-11) because
it assumed comparison of VS version numbers works. Now it does.
The Intel Fortran plugin forgets to create the output directory into
which it will write a DLL's import library. Utilize the fix added by
commit f4b3bdc6 (Create an exe's implib output dir for VS, 2009-06-15)
and generalized by commit 764ac980 (Generalize exe implib dir creation
for VS, 2009-06-16). Create a pre-link rule to make the directory.
VS 6 forgets to create the output directory for a static library if it
differs from the intermediate files directory. We work around this VS
bug by creating a pre-link event on the library target to make the
directory.
This commit removes use of configuration-less cmTarget::GetDirectory()
by the VS 6 generator (except for compatibility with user templates).
We replace OUTPUT_DIRECTORY_<CONFIG> tokens in the templates using the
per-configuration result of cmTarget::GetDirectory(config).
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
CMake Makefile generators silently ignore missing CMakeLists.txt files
and just treat the source directory as if it had an empty input file.
This will be addressed with a new CMake Policy, but for now we make the
VS generator consistent with the Makefile generator behavior. The VS
generator will need to handle the OLD behavior of the policy anyway.
This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member. Now the
global generator can be retrieved automatically, so we can drop the
method argument.
Since utility targets have no main output files like executables or
libraries, they do not define an output directory. This removes a call
to cmTarget::GetDirectory from cmLocalVisualStudio{6,7}Generator for
such targets.
VS 6 forgets to create the output directory for an executable's import
library in case the exe dllexport-s symbols. We work around this VS bug
by creating a pre-link event on the executable target to make the
directory.
In cmLocalVisualStudio6Generator we generate pre-build, pre-link, and
post-build events into project files. This refactors the generation
code for the three event types into a private EventWriter class to avoid
duplicate code.
Previously we rejected all preprocessor definition values containing
spaces for the VS6 IDE generator. In fact VS6 does support spaces but
not in combination with '"', '$', or ';', and only if we use the sytnax
'-DNAME="value with spaces"' instead of '-D"NAME=value with spaces"'.
Now we support all definition values that do not have one of these
invalid pairs. See issue #8779.
The add_definitions() command and COMPILE_DEFINITIONS dir/tgt/src
properties support preprocessor definitions with values. Previously
values were not supported in the VS6 generator even though the native
tool supports them. It is only values with spaces that VS6 does not
support. This enables support and instead complains only for values
with spaces. See issue #8779.
Stephen Kelly
Brad King
Kitware Robot
David Cole
Bill Hoffman