Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
920a046 QtAutomoc: Eliminate compiler warning
b00463f QtAutomoc test: Pass QT_QMAKE_EXECUTABLE
e78ce44 Fix automoc with VS builds: apply patch from Bill
71165e9 Silence warning in automoc: use long instead of int
1879bcc Fix build: use std::ios::out|ios::trunc instead of std::ios_base::out
678e124 Only enable the automoc test after checking that Qt4 works
71c29d1 Fix bootstrap test with automoc
afb3edc Fix warnings
add30e9 Fix build: non-void function must return a value
7e6d845 Automoc.cmake is not needed anymore
2963d0b Fix logic which decides when to execute automoc test
77a5c6e Add documentation for AUTOMOC, add initialization via CMAKE_AUTOMOC
bf8ef77 Add a test for automoc
d045fd4 Nicer progress message for the automoc target
50cd6ce Move automoc processing from add_executable/library to cmGlobalGenerator
cbaac2a Remove trailing whitespace
c27607b Refactor SetupAutomocTarget() so it can be run after creating the target
24d9b7d Remove trailing whitespace
58b7fe6 Use cout instead of printf()
72caf4d Add the generated automoc.cpp file to the cleaned files
ddb517d Color output when running moc
9303295 Initialize verbose based onb the env.var.
ace1215 Move code for parsing a cpp-file from the big loop to separate function
735a5bb Fix line lengths
83b730c Add AUTOMOC to the add_library() command
126c6ea Add the cmake module required currently for automoc
de91feb Remove the need to check for .h/.cxx during buildtime
d65689a Add actual automoc code from automoc
d1c0a5f Start implementing skeleton for automoc in cmake
a65011b Start work on automoc: add empty cmQtAutomoc class
Makes VS 7, 8 and 9 generators consistent with the VS 10
generator. Adds the "AdditionalIncludeDirectories" attribute
at the vcproj level so that all idl files inherit the /I
command line args.
For custom commands in VS2010 Fortran projects the INTDIR variable
is different than in the rest of the solution because Intel
fortran still uses the old VS project files even in VS2010. So,
we replace $(Configuration) directly in the project files. I have also
added a FortranOnly test that tests this feature and is run on any
generator that has Fortran abilities.
Thanks to Pau Garcia i Quiles for the inspiration for the patch.
I've tweaked it a bit compared to what's in the bug tracker: this
commit does not allow empty global variable names.
I also added usage of the new feature to an existing test. Although
it has no effect on the resulting Visual Studio projects, you can
verify that the VSResource test produces a non-empty globals section
in the generated .vcproj(x) files.
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.
008d116 VSResource: Avoid windres /D with quoted spaces (#11695)
8f9919d Avoid space in rc /D values for VS6 and Cygwin (#11695)
78fe97f Fix line too long KWStyle issue (#11695)
6627560 VS10: Escape double quote chars in defines for rc files (#11695)
To get rc defines to work in the VS10 IDE requires \" when
constructing PreprocessorDefinitions strings. This is different
than defines for cl.
Also, per-file rc defines were not being generated. Fix that, too.
Factor out generation of SccProjectName, SccLocalPath, and SccProvider
from cmLocalVisualStudio7Generator::WriteProjectStart and call it from
cmLocalVisualStudio7Generator::WriteProjectStartFortran too.
e33cbda VSMidl Test: Use correct include_directories with VS6 (#11461)
262da91 Prohibit space in HOME value for VSMidl test.
13caaa3 VS10: Finish Midl support (#11461)
This commit addresses all of the following:
http://public.kitware.com/Bug/view.php?id=8165http://public.kitware.com/Bug/view.php?id=10687http://public.kitware.com/Bug/view.php?id=11311http://public.kitware.com/Bug/view.php?id=11461
With this commit, the midl support for VS10 is as
complete as midl support ever was for VS9 and earlier.
The VSMidl test should run on all Visual Studio
generator based dashboards.
CMake no longer sends C++ compiler /D flag values
to the midl compiler in Visual Studio generated
projects. I think if we want to add that in the
future, we should add a way to pass midl compiler
specific flags and perhaps an optional way to add
in the C++ definitions, too. For now, not sending
them along gets past the immediate problem wherein
idl files in a CMake VS generated project just didn't
work at all.
The VSMidl test added in this commit was inspired by
the patch attached to 8165.
The test had to be modified such that it will run in
a directory whose name contains no spaces. There is an
existing bug filed against VS10's midl asking Microsoft
to fix that problem. But for now, the test added in this
commit works by copying the source directory to a location
that avoids spaces in the directory names.
Inspired-By: Robert Lenhardt
Look for the "/threads", "/libs:dll", and "/dbglibs" flags and convert
them to the proper RuntimeLibrary attribute value in the IDE. This is
a 3-to-1 flag mapping and such needs special handling in the parser.
The SubSystem attribute value must be "subSystemConsole" or
"subSystemWindows", not "1" or "2". Commit 20f49730 (Reset
platform/compiler info status for each language, 2010-09-28) exposed
this bug by (correctly) passing the /libs:dll flag to the compiler,
which chokes the linker if a value for "/subsystem:" is not given.
I naively assumed in my previous commit that the Convert call
would correctly convert a relative path file name correctly
relative to the makefile's current output directory. It actually
converts it relative to the process's current working directory.
So it would be different depending on how you launched cmake-gui.
This commit ensures that the generated files are always the same
by starting with a full path to begin with, based on the makefile
GetCurrentOutputDirectory method.
This is especially important for the Visual Studio 10
generator and its quirky current working directory
behavior.
Also, emit more information about exactly what files are
out of date when cmakeCheckStampFile returns false.
The PDB file name for VCLinkerTool is specified by the xml attribute
"ProgramDatabaseFile", not "ProgramDataBaseFile" (note the lower-case
character 'b'). VS seems to cope with the incorrect capitalization but
the combination of VS 7.1 and Incredibuild does not. See issue #10614.
The Intel Fortran plugin to VS defines VFFortranCompilerTool as the
compiler tool. This commit fixes generated projects to use that tool
for per-source settings instead of VCCLCompilerTool. We were already
using it for target-wide compiler settings.
In VS 8 and greater this commit implements
add_dependencies(myexe mylib) # depend without linking
by adding the
LinkLibraryDependencies="false"
option to project files. Previously the above code would cause myexe to
link to mylib in VS 8 and greater. This option prevents dependencies
specified only in the solution from being linked. We already specify
the real link library dependencies in the project files, and any project
depending on this to link would not have worked in Makefile generators.
We were already avoiding this problem in VS 7.1 and below by inserting
intermediate mylib_UTILITY targets. It was more important for those
versions because if a static library depended on another library the
librarian would copy the dependees into the depender! This is no longer
the case with VS 8 and above so we do not need that workaround.
See issue #9732.
In Visual Studio project files we pass compiler flags to the whole
target based on the linker language, which works for MS tools and
combinations of C and C++. For the Intel Fortran plugin though the
generated .vfproj files should never contain C or C++ options.
We generate .vfproj files only for targets consisting only of Fortran
code. Now that the linker language is computed transitively through
linking it is possible that the linker language is C++ for an otherwise
Fortran-only project. This commit forces Fortran as the linker language
for the purpose of specifying target-wide flags in .vfproj files.
See issue #9719.
We recognize .def source files and map them to the /DEF:<file> option in
the MSVC tools. Previously this worked only for shared libraries. This
commit cleans up the implementation and makes it work for executables
too. See issue #9613.
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.
The commit "Generate proper Intel Fortran project version" replaced the
hard-coded 9.10 value with a runtime registry lookup of the real
version. Version 10.1 actually uses project file format 9.10, so this
commit switches it back for that version. See issue #9169.
The Intel Visual Fortran compiler plugin for MS Visual Studio may be one
of several versions of the Intel compiler. This commit teaches CMake to
detect the plugin version and set the version number in .vfproj files.
See issue #9169.
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.
Brad King
David Cole
Alex Neundorf
Bill Hoffman
Sebastian Herbst
Philip Lowman
James Bigler
Brian Bassett
Patrick Gansterer