| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Make CMake compile with -DUNICODE. Make it possible for the 8 bit
encoding to eventually be UTF-8 instead ANSI.
|
|\
| |
| |
| |
| | |
bf1db49 VS: Map /Fd to ProgramDataBaseFileName for VS 7,8,9 (#14577)
|
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit 42ba1b08 (VS: Separate compiler and linker PDB files,
2013-04-05) the VS generators no longer add ProgramDataBaseFileName.
Therefore we should allow projects to do so by mapping the /Fd option.
For VS >= 10 our flag tables map /Fd to ProgramDataBaseFileName already.
Add the mapping for VS 7, 8, and 9.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Teach the VS 7-9 generators to honor the
VS_DOTNET_TARGET_FRAMEWORK_VERSION
target property. This was already done for VS >= 10 by commit cfe6300a
(VS: Add support for .NET target framework version, 2013-06-14).
Inspired-by: mar.na@t-online.de
|
| |
| |
| |
| |
| |
| | |
Lookup the Intel VS plugin version on demand in the VS global generator,
compute the corresponding .vfproj format version number, and memoize it.
Add it as a CMAKE_VS_INTEL_Fortran_PROJECT_VERSION platform definition.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
|
|
|
|
|
|
|
|
| |
The version of Intel Fortran that actually uses 9.10 as a project format
is very old. Default to the latest format version (11.0) and use the
older format only when known to be necessary.
Suggested-by: Dick Munroe <munroe@csworks.com>
|
|\
| |
| |
| |
| |
| | |
2268c41 Optimize custom command full-path dependency lookup
eccb39d VS 6,7: Refactor local generators to avoid GetSourceFileWithOutput
|
| |
| |
| |
| |
| |
| | |
Use the cmSourceFile returned by AddCustomCommandToOutput instead of
throwing out the return value and looking it up with
GetSourceFileWithOutput.
|
|/
|
|
|
| |
Set the EntryPointSymbol only when it has not been set before
and use the correct symbol depending on the usage of Unicode.
|
|
|
|
|
| |
Introduce cmLocalGenerator::GetStaticLibraryFlags() to have a central
function for getting the linker flags for a given target.
|
|
|
|
| |
Refactor to create AddCompileDefinitions.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the cmLocalGenerator GetCompileOptions method with an
AddCompileOptions method since all call sites of the former simply
append the result to a flags string anyway.
Add a "lang" argument to AddCompileOptions and move the
CMAKE_<LANG>_FLAGS_REGEX filter into it. Move the call sites in each
generator to a location that has both the language and configuration
available. In the Makefile generator this also moves the flags from
build.make to flags.make where they belong.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Generate the default AssemblerListingLocation through the flag map so
that it can be overridden by a user /Fa flag. Also teach the VS 7-9
generators to map /Fa to AssemblerListingLocation.
While at it, fix the AssemblerListingLocation default value to have a
trailing slash after the configuration name. This ensures it will be
treated as a directory and not a file name.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7cc2805 Docs: Clarify wording "flag used" => "flag (to|will) be used"
2378a69 Docs: Clarify that CMAKE_*_(PREFIX|SUFFIX) affect filenames
56ca34d Docs: Update description of CMAKE_(BUILD_TYPE|CONFIGURATION_TYPES)
2bab472 VS10: add detailed comment about MIDL processing
e619111 Explain distribution of Win9x binary on all Windows versions.
5ca4336 FindwxWidgets: add DOC strings with usual style
f57800d Fix spelling and typos (product names)
bf019d7 Fix spelling and typos (non-binary)
ddac8d3 Fix spelling and typos (affecting binary data / module messages)
86832ce Fix spelling and typos (affecting users)
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS tools create two types of PDB files as explained here:
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.80%29.aspx
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.90%29.aspx
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.100%29.aspx
One is created by the compiler (/Fd) and the other by the linker (/pdb).
The two options should not specify the same file. Split them up.
In the VS IDE generators, simply drop ProgramDataBaseFileName to
take the VS default "/Fd$(IntDir)vc$(PlatformToolsetVersion).pdb".
In the Makefile generators, set "/Fd" on the compile line to be
the directory containing object files (with a trailing slash the
compiler will add the "vc$(PlatformToolsetVersion).pdb" filename
automatically). Drop the /Fd option from the exe link command
line and add "/pdb" instead (already done for dll linking).
Update these rules for both MSVC and Intel tools.
Drop support for PDB_OUTPUT_DIRECTORY and PDB_NAME in STATIC
libraries because the generated .pdb files are only from /Fd
and not real linker-generated .pdb files. Update documentation to
clarify that the PDB_* properties are only for linker .pdb files.
This regresses the PDBDirectoryAndName test for STATIC libraries.
Since it is not clear at this time what should be done for STATIC
library .pdb files, comment out the relevant portion of the test
and leave a TODO comment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Teach the WriteGroup method return true if a group or any of its
children have source files. Have children write their output to a
temporay cmOStringStream. Add it to the real output only if not empty.
|
| |
|
|
|
|
|
| |
This fixes a link error in VS 2005: unresolved external symbol
__DllMainCRTStartup@12.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3a1006e VS: Added "Deploy" at project configuration for WindowsCE targets
40c36c9 VS: Make DetermineCompilerId working with WinCE too
038df9e VS: Allow setting the name of the target platform
6fe4fcb VS: Add parser for WCE.VCPlatform.config to read WinCE platforms
2118a20 VS: Support setting correct subsystem and entry point for WinCE
6920fed VS: Change variable type of Name from const char* to string
102521b VS: Change variable type of ArchitectureId from const char* to string
332dc09 VS: Add static method to get the base of the registry
d41d4d3 VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefile
14861f8 VS: Remove TargetMachine for linker when checking compiler id
|
| |
| |
| |
| |
| | |
WinCE has only one SubSystem. So the WIN32_EXECUTABLE property
must be handled via the EntryPointSymbol in the vcproj files.
|
|/
|
|
|
|
|
| |
As we can't move all linking related code from cmTarget, it makes
sense to reverse the move in some cases.
This reverts commit 4f5384e75c6a00d110d3fa3f555a3f6a4f31bb46.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| | |
2ccca05 Run PDBDirectoryAndName test on MSVC and Intel
efc83b3 Document that PDB_(NAME|OUTPUT_DIRECTORY) are ignored for VS 6
b294457 Verify that PDB_(NAME|OUTPUT_DIRECTORY) are honored in test
3f60dbf Add PDB_OUTPUT_DIRECTORY and PDB_NAME target properties (#10830)
|
| |
| |
| |
| |
| |
| |
| | |
This enables changing the name and output folder of the debug symbol
files produced by MS compilers.
Inspired-by: Thomas Bernard <thomas.bernard@ipetronik.com>
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our Git commit hooks disallow modification or addition of lines with
trailing whitespace. Wipe out all remnants of trailing whitespace
everywhere except third-party code.
Run the following shell code:
git ls-files -z -- \
bootstrap doxygen.config '*.readme' \
'*.c' '*.cmake' '*.cpp' '*.cxx' \
'*.el' '*.f' '*.f90' '*.h' '*.in' '*.in.l' '*.java' \
'*.mm' '*.pike' '*.py' '*.txt' '*.vim' |
egrep -z -v '^(Utilities/cm|Source/(kwsys|CursesDialog/form)/)' |
egrep -z -v '^(Modules/CPack\..*\.in)' |
xargs -0 sed -i 's/ \+$//'
|
|
|
|
|
|
|
| |
I have tested that it works with:
Microsoft Visual Studio 10.0.40219.1
Intel Visual Fortran 13.0.0.041 Beta Build 20120425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
| |/
| |
| |
| |
| |
| |
| | |
For Visual Studio using the Preprocessor Define _SBCS. This behavior
is similar to the way that _UNICODE and _MBCS work already.
Added tests to confirm this behavior.
|
|/
|
|
|
|
|
|
|
| |
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
|
|
|
|
|
|
|
|
|
| |
Commit 1be4b6f4 (Order VS local generator Version ivar values
consistently, 2011-11-10) fixed the Version ivar of the VS 10 local
generator by setting it correctly to 10 instead of leaving it at 7.
This broke generation of .vfproj files for the Intel Fortran plugin to
VS 10 by mixing VS 9 and 10 formats together in one file. Teach the
local generator to pretend the Version is 9 for Intel Fortran targets.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|