Add a dummy mainCRTStartup() function, since the linker searches for
it instead of main() and set the CMAKE_SYSTEM_* variables depending
on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
Parse the WCE.VCPlatform.config file, which contains the installed
WindowsCE SDKs in XML format, and add possibility to generate
Visual Studio generators for them.
Implement support for multiarch include directories as specified here:
https://wiki.ubuntu.com/MultiarchCross
Generalize the multiarch feature added in commit b41ad3b3 (Teach
find_(library|package) about Linux multiarch, 2011-06-08) to the
find_path and find_file commands. Teach them to search
<prefix>/include/<arch> whenever they would search <prefix>/include.
When adding more platforms to the Visual Studio generators a simple
regular expressing can not handle all cases anymore. This new
define holds the name of the Visual Studio target platform.
add_custom_command can have empty DEPENDS arguments, which
was triggering invalid makefile generation for the NMake
Makefiles generator. We were mistakenly emitting the build
directory appended with "/" plus the empty string... which
was then translated to a string ending in \" in build.make...
which nmake choked on.
The solution is not to emit any dependency when the input
DEPENDS is the empty string. Return early from GetRealDependency
in this empty input case.
This is for consistency throughout cmake. The cmsys version exists
becaues uses of auto_ptr types as return types does not work with
some implementations in ancient compilers.
Following from the discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5170
(Re: Generator expressisons in target properties, 26 Oct 12:10)
we can't split cmTarget API for linking into cmGeneratorTarget. In
the future we will probably also need to move the include and compile
definitions API back to cmTarget so that it can be used by export().
75ebebc VS: Remove platform specific generator files
8b62080 VS: Remove EnableLanguage from platform-specific generators
5bdf011 VS: Remove GetPlatformName from platform-specific generators
8d42ab4 VS: Fix ArchitectureId of Visual Studio 10 IA64 generator
6f439b3 VS: Remove AddPlatformDefinitions from platform-specific generators
5170a88 Make cmGlobalGenerator::GetDocumentation() a static function
04ff866 Allow a GeneratorFactory handling of more than one generator
984ebc3 Search generator in cmake::ExtraGenerators before in cmake::Generators
30a6950 Add cmGlobalGeneratorFactory::GetGenerators()
e8f8414 Introduce the abstract class cmGlobalGeneratorFactory
On some systems, ${QT_INCLUDE_DIR} is reported by gcc as a builtin
include search dir. Some projects use this information to extend
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES.
In cmake 2.8.10 now the targets are queried for the include directories
they use. When they return the result, the include dirs contained in
CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES have been removed.
In cmake 2.8.9 and below the INCLUDE_DIRECTORIES directory property
was queried, where this had not been stripped.
So, in those projects which modify the implicit include dirs variable,
on systems where ${QT_INCLUDE_DIR} is reported by gcc, this directory,
e.g. /usr/lib/include/qt/, was not given anymore to moc. This made moc
not find required headers, so the build broke.
Simply giving the full CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES to moc
is no solution either, since moc can't handle some of the headers it
finds then (https://bugreports.qt-project.org/browse/QTBUG-28045).
So now cmake checks CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES, and if this
contains ${QT_INCLUDE_DIR}, and the target reports that it uses
${QT_QTCORE_INCLUDE_DIR} but not ${QT_INCLUDE_DIR}, ${QT_INCLUDE_DIR}
is added to the include dirs given to moc.
Alex
Pass the name of the requested generator to the generator factory,
which is now responsible to check if it can create a matching
generator for the name. This allows us to add more logic to the
factory in a next step, so that not every possible generator needs
to get registered explicit in cmake::AddDefaultGenerators().
Since ExtraGenerators does not contain items, which are in Generators
too, there is not change in behaviour. The benefit of this change is,
that the lookup in the Generators map is now only done once.
Since commit ca39c5cd (Optionally allow IMPORTED targets to be globally
visible, 2012-01-25) cmGlobalGenerator has a second member that tracks
targets with global scope. We must initialize the new 'ImportedTargets'
member wherever the old 'TotalTargets' member is initialized. Without
this initialization the ImportedTargets member is left with dangling
pointers during a same-process re-configuration.
This patch sets the FOLDER target property for the automoc target
to the same value as of the actual target. This organizes the targets
in IDEs with folders better.
Inspired-by: Mike Gelfand
Alex
737534c Remove references to ancient and removed parts of the code.
21e8a08 Resolve ambiguity warning regarding use of && and ||.
5f6432f Resolve warnings about shadowing parameters and local variables.
9f16d42 Resolve warnings about used enum values in switch blocks.
bd8bdb6 Resolve warnings about unused variables.
Change test if DEL key is allowed from 'curcol > 0' to 'curcol >= 0', as
deleting forward is reasonable in the first column (and probably
expected by users to work).
Support for DEL was first added in commit b3b43508 (BUG: fix for 6462,
delete key should delete the current char, 2008-08-19). The commit
appears to have copied the original logic from the backspace code so the
old 'curcol > 0' logic was accidental rather than intentional.
This is not ambiguous to the compiler, but it may seem ambiguous to
the reader.
From reading 3a53005f (Build object library targets in VS), 5484550a
(Detect and set Unicode character set in VS 10), and 9e01aefd (VS:
Add support for WinRT project properties (#12930)), this appears to
be the intentional semantic.
- file(WRITE): add configure_file() decoupling hint
- function(): definitely mention PARENT_SCOPE
- include_directories(): mention possible results of SYSTEM setting
- macro(): mention scope specifics of function()
- message(): improve SEND_ERROR / FATAL_ERROR docs, since people said it's not obvious
This command works only when building projects using the same
architecture as the running CMake binary. Since it was introduced
CMake has learned macro() and function() to add commands, and the
execute_process() command to launch advanced external computations.
Add a RunCMake.load_command test to verify the warning appears.
828d4f5 Add several get_property() tests
82106e3 GetProperty test: move doc property tests into main process
56125a3 list: add tests for CMP0007 behavior
48ed48f Add test to secure the file(GLOB empty) behavior.
c2a6cb6 file: remove dead code
07251a8 Consolidate list() argument count testing
1b078c3 Add tests for list() invalid arguments
f560977 Add tests for list() argument count
d211e5d CMakeTests: allow to call the check_cmake_test macro with a given file
The code handling IMPLICIT_DEPENDS was only able to track a single file,
the latest file replaced earlier files in the list.
The documentation now mentions that the language has to be prefixed to
every file and the test now uses two implicit dependencies, where only
the second is modified to trigger re-running of the custom command.
Alex
Inspired-by: Michael Wild <themiwi@users.sourceforge.net>
Some dependency-generators (such as cmDependsFortran) generate multiple
entries per depender, so erasing the dependency vector for each depender
found loses earlier dependencies.
Signed-off-by: Michael Wild <themiwi@users.sourceforge.net>
This patch is heavily inspired by Michael Wild.
The interfaces cmDepends::Write and cmDepends::WriteDependencies where
extended to allow multiple dependees (sources) per depender (object).
cmDepends::Write first collect all dependencies into a std::set before
passing it to cmDepends::WriteDependencies.
cmDependsC::WriteDependencies also first collects all explicit and
implicit dependencies into a std::set and only then writes
depend.{internal,make}. The implementation of cmDependsFortran simply
loops over all sources and proceeds as before, whereas the cmDependsJava
implementation is as trivial as before.
This is for preventing exponential growth of depend.{internal,make} in
the next commit which fixes dependency-vector erasure in
cmDepends::CheckDependencies.
Inspired-by: Michael Wild <themiwi@users.sourceforge.net>
This is intentionally a separate commit, so the parent commit which
changes the logic is small and not mixed with formatting (indentation)
changes. So, this patch here does not change any logic.
Alex
Since CMake 2.8.7 no src-path entry was generated anymore, in response to
http://www.cmake.org/Bug/view.php?id=12213
Before that a src-path entry was added for each linked resource.
Now only one src-path entry is added, for the ${CMAKE_SOURCE_DIR}.
According to
http://www.cmake.org/Bug/view.php?id=13596
this makes the indexer behave better.
Alex
This patch reduces a bit code duplication by changing the way how the
case that we already have valid dependencies for a file is handled.
Instead of having the code for writing the depend-files twice,
we now fill the existing dependencies into the same set and then
write it out once at the end of cmDependsC::WriteDependencies()
Alex
Inspired-by: Michael Wild <themiwi@users.sourceforge.net>
The ComputePDBOutputDir added by commit 3f60dbf1 (Add
PDB_OUTPUT_DIRECTORY and PDB_NAME target properties, 2012-09-25) falls
back to the current binary directory instead of the target output
directory as before. When no PDB_OUTPUT_DIRECTORY property is set we
instead should fall back to the target output directory where .pdb files
used to go before the new property was added.
The file command requires at least two arguments, so guarding the GLOB and
MAKE_DIRECTORY command is not necessary. Changed it for an assert to keep the
protection.
66759ee find_library: Optionally consider all names in each directory
9cb68b1 find_library: Generalize helper macro in test case
b64dd76 find_library: Simplify framework search logic
531c71b find_library: Refactor internal name iteration
Previously, setting CPACK_POSTFLIGHT_SCRIPT had no effect in
component mode, when CPACK_COMPONENTS_ALL was set.
In component mode, a .mpkg is created that contains multiple .pkg's.
Because postflight scripts only work in a .pkg, add another .pkg to the
.mpkg and put the postflight script in that.
This is the same approach taken by the PackageMaker GUI when adding
a postflight script to a metapackage.
Fix the VS 10 link flag map to name the project file entries correctly.
The VS 11 link flag map already has the correct names. Generate the
entries in the <PropertyGroup> along with incremental linking options.
Drop them from the <Link> element because VS does not use them.
Avoid collecting the link options twice. Collect them once in a
LinkOptions member and use it from both places. We already do this for
compiler options with the ClOptions member.
...in generated sub-directory sln files.
Thanks to rlandert for the bug report and proposed patch.
The method WriteTargetsToSolution gets called possibly multiple times,
once per sln file, (-> once per "project" command).
Before accumulating folder names in VisualStudioFolders, clear it
first, so it doesn't have stale entries in it from the previous
sln file.
The path must be either absolute or relative to the working directory
from which the makefile will be loaded. In subprojects this is not
relative to the top of the build tree.
Reported-by: David Weese <tre@gmx.de>
e386992 GexEx: Validate Target names and property names differently.
95d590d GenEx: Create cmGeneratorTargets for imported targets.
0442104 GenEx: Add an accessor for imported targets in a makefile.
We're going to need to link to them, and all the linking API is moving
to cmGeneratorTarget.
Skip imported targets when iterating over cmGeneratorTargets in places
where we only want targets we build. The GetGeneratorTargets result now
includes IMPORTED targets where it didn't before. The GetTargets
result, which was what used to be called in these methods does not
include IMPORTED targets. This doesn't relate to any known bugs, but in
some future uses of GetGeneratorTargets it will be important, so
starting the convention and being deliberate now is a good idea.