In vs2010 a bad project file could be generated if a .c or .cxx file
was marked with HEADER_FILE_ONLY, if it was in a library that contained
both c and c++ code. This fixes the error in the code, and adds a test
for this case.
If a .sln file refers to a project file with a leading ".\", as in
".\foo.vcxproj" instead of just "foo.vcxproj" or a full path then
msbuild behaves strangely. Whenever target foo is built as a dependency
of another target, msbuild brings multiple configurations up to date
instead of just the requested configuration!
Avoid a leading ".\" in project file references to avoid this behavior.
This alternative fix to that attempted by commit 57e71533 (Avoid msbuild
idiosyncrasy that builds multiple configs, 2010-12-10) avoids use of
full path project file references which vcbuild does not support.
This reverts commit 57e71533f4.
While "msbuild" can handle full paths to project files in solutions,
the old "vcbuild" used for VS < 10 cannot. We will need another
way to fix issue #11594.
For prior versions of Visual Studio we would intentionally pass
"/nologo-" for "verbose makefiles" (CMAKE_VERBOSE_MAKEFILE ON)
when the caller did not already explicitly specify either /nologo
or /nologo-. And we still do. For the prior versions.
This had the side effect of always passing /nologo- for try_compile
operations because try_compile generates projects that have verbose
makefiles on.
However, starting with Visual Studio 10, the compiler emits
"cl ... warning D9035: option 'nologo-' has been deprecated"
when passed "/nologo-".
Therefore, this commit removes setting "/nologo-" for verbose
makefiles in the Visual Studio 10 case to avoid emitting a
warning for every single invocation of the compiler in a given
build.
With Visual Studio 10, we do not set this flag either way
and therefore, the generated project has no value for this
setting and gets Visual Studio's default value, which is
of course "/nologo", which does not produce a warning.
With Visual Studio 10, a caller can still force "/nologo-"
if desired by adding it explicitly to CMAKE_C_FLAGS or
CMAKE_CXX_FLAGS.
One of Cygwin's goals is to build projects using the POSIX API with no
Windows awareness. Many CMake-built projects have been written to test
for UNIX and WIN32 but not CYGWIN. The preferred behavior under Cygwin
in such projects is to take the UNIX path but not the WIN32 path.
Unfortunately this change is BACKWARDS INCOMPATIBLE for Cygwin-aware
CMake projects! Some projects that previously built under Cygwin and
are Cygwin-aware when they test for WIN32 may now behave differently.
Eventually these projects will need to be updated, but to help users
build them in the meantime we print a warning about the change in
behavior. Furthermore, one may set CMAKE_LEGACY_CYGWIN_WIN32 to request
old behavior during the transition.
Normally we avoid backwards incompatible changes, but we make an
exception in this case for a few reasons:
(1) This behavior is preferred by Cygwin's design goals.
(2) A warning provides a clear path forward for everyone who may see
incompatible behavior, and CMAKE_LEGACY_CYGWIN_WIN32 provides a
compatibility option. The warning and compatibility option both
disappear when the minimum required version of CMake in a project is
sufficiently new, so this issue will simply go away over time as
projects are updated to account for the change.
(3) The fixes required to update projects are fairly insignificant.
Furthermore, the Cygwin distribution has no releases itself so project
versions that predate said fixes tend to be difficult to build anyway.
(4) This change enables many CMake-built projects that did not
previously build under Cygwin to work out-of-the-box. From bug #10122:
"I have built over 120 different source packages with (my patched)
CMake, including most of KDE4, and have found that NOT defining
WIN32 on Cygwin is much more accurate." -- Yaakov Selkowitz
A fully compatible change would require patches on top of these project
releases for Cygwin even though they otherwise need not be aware of it.
(5) Yaakov has been maintaining a fork of CMake with this change for the
Cygwin Ports distribution. It works well in practice. By accepting the
change in upstream CMake we avoid confusion between the versions.
CMake itself builds without WIN32 defined on Cygwin. Simply disable
CMAKE_LEGACY_CYGWIN_WIN32 explicitly in our own CMakeLists.txt file.
Previously, we would search in the Windows registry for the path
to makensis, and fail immediately if we could not read the registry
value, assuming that it was simply not installed.
This change looks for makensis in the PATH even if the registry value
is not there, enabling the scenario where makensis is installed without
admin privileges and never even touches HKEY_LOCAL_MACHINE during the
non-admin install.
In VS9 and previous versions, :VCReportError is the goto label
to jump to after a failed custom command. It stops the build
before it tries to go any further.
In VS10, :VCEnd is the correct label to use.
Create a method in the VS generators to provide the correct
line of script to use for each version of Visual Studio.
For more internal details, search for VCEnd in the
C:\Program Files\MSBuild directory.
The KWSys SystemTools::GetMaximumFilePathLength method is poorly
conceived and should not be used. The cmDepends code honors its own
MaxPath buffer size. Just hard-code it.
The first instinct of a lot of users is to use file(GLOB) to assemble
lists of sources. Add a warning to the help text stating that it should
not be used for this purpose and briefly explain why.
Suggested-By: Ryan Pavlik
A cycle exists when the DFS returns to the root node, not just when
multiple paths lead to the same node.
Inspired-By: Alexander Esilevich <aesilevich@pathscale.com>
Evaluate in the COMMAND arguments of custom commands the generator
expression syntax introduced in commit d2e1f2b4 (Introduce "generator
expressions" to add_test, 2009-08-11). These expressions have a syntax
like $<TARGET_FILE:mytarget> and are evaluated during build system
generation. This syntax allows per-configuration target output files to
be referenced in custom command lines.
The target_link_libraries command requires its first argument to be a
target in the current directory. Document this and update the error
message to be more specific. While at it, format the error message with
a call stack.
Previously the OUTPUT arguments of add_custom_command were not
slash-normalized but those of add_library and add_executable were.
This caused the example
add_custom_command(OUTPUT a//b.c ...)
add_library(... a//b.c ...)
to fail at build time with "no rule to make a/b.c". Fix this and modify
the CustomCommand test to try it.
This method replaces '//' with '/' to make the paths look nicer.
Originally it correctly skipped a leading '//' in a UNC path as the
comment says. However, commit "Removed extra variable initializations"
(2005-04-15) accidentally removed the "pos=1" initializer. It was then
incorrectly restored by commit "Added missing variable initialization"
(2005-04-15) as just "pos=0". Restore the proper initializer.
The test for this added by commit "better coverage" (2006-07-31)
included incorrect output for a sample UNC-like path. Fix it.
Pass the full version to cmake_minimum_required(VERSION) in generated
CMake files for try_compile projects. This tells CMake not to use any
backward compatibility behavior while processing code it generates.
27ee50a Add ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT as a ADVANCED cache variable (#9631)
50d21d4 Add cache var CMAKE_ECLIPSE_MAKE_ARGUMENTS when using the Eclipse generator
10f01ae Remove unused parameter "root" in some VS generator methods
57e7153 Avoid msbuild idiosyncrasy that builds multiple configs (#11594)
7728172 Remove unused variable "rootdir" in VS generators
Remove a boolean parameter of cmGlobalGenerator::CreateGlobalTarget that
is never set to true anymore. Remove global target "consolidation" loop
because no global targets exist before it runs anymore.
Commit e01cce28 (Allow add_dependencies() on imported targets,
2010-11-19) started using cmMakefile::FindTargetToUse to follow
dependencies, including those of GLOBAL_TARGETs like INSTALL and
PACKAGE. Since global targets exist in every directory, dependencies
between them must be traced within each directory too.
Teach FindTargetToUse to check the current directory before checking
globally. For global targets this will find the local copy. For for
normal targets this will be a no-op because they are globally unique.
This variable can be set to command line arguments which will be passed
to make when eclipse invokes make, e.g. you can enter "-j8" to get
8 parallel builds (#9930)
Alex
This authorize more control because one can set
CPACK_ARCHIVE_COMPONENT_INSTALL to ON globally
and then set it selectively to OFF inside
a CPack project config file.
Sidenote: GetOption ought to be a 'const' method.
If a .sln file refers to a project file with a leading ".\", as in
".\foo.vcxproj" instead of just "foo.vcxproj" or a full path then
msbuild behaves strangely. Whenever target foo is built as a dependency
of another target, msbuild brings multiple configurations up to date
instead of just the requested configuration!
Refer to all project files by full path to avoid this behavior.
The soname generation code was compile-time selected instead of runtime
selected. The result is that a Mac-compiled cmake used to cross-compile
Mac -> Unix generates an soname of the form libfoo.x.y.so instead of
libfoo.so.x.y as expected. Instead do a runtime check based on the
target platform.
Inspired-By: George Staikos <staikos@kde.org>
Avoid tracing dependencies of GLOBAL_TARGET targets. The build system
generators are not designed to handle any dependencies that may be
discovered. Global targets are only generated by CMake and never have
commands that reference targets built in the project anyway.
The exception is when building CMake itself there is a special case to
use the just-built "cmake" binary in the "install" target so that CMake
can replace itself on Windows. Even in this special case we do not want
to let the "install" target depend on the "cmake" target. Doing so
breaks cases like "make -j4 install".
Commit "merge in changes for beos support" (2006-12-04) added a realpath
call for every directory parsed out of a PATH-style environment
variable. No reason was given in the commit message or comments.
The call incorrectly resolves symlinks in referenced paths. Remove it.
If BeOS support really needs it then it can be restored for that
platform with a full explanation.
The cmCustomCommandGenerator::GetCommand method completely replaces the
purpose of this method. Re-implement GetRealLocation inline at the only
remaining call site and remove it.
The Makefile, VS, and Xcode generators previously duplicated some custom
command line generation code. Factor this out into a separate class
cmCustomCommandGenerator shared by all generators.
A custom command may name a target created by add_custom_target in its
DEPENDS field. Treat this case as a target-level dependency only since
a custom target provides no standard file on which to add a file-level
dependency.
Imported targets do not themselves build, but we can follow dependencies
through them to find real targets. This allows imported targets to
depend on custom targets that provide the underlying files at build
time.
Commit 60cd72d0 (Cleaned up generation of symbolic rules, 2006-02-15)
incorrectly made these Makefile targets .PHONY even though the build
rule touches an actual file. Correct it so that the copy_f90_mod and
touch steps do not happen on every "make".
Commit 34e1ac24 (Create Fortran info variables for .mod behavior,
2010-11-12) incorrectly taught GetFortranModuleDirectory to return a
relative path. We really want to use "." as the module directory only
as a workaround for compilers that do not do so by default. Therefore
we need this default only when generating the compiler command line and
not when scanning dependencies.
Revert the previous change to GetFortranModuleDirectory and apply the
change only at one of its call sites.
Commit 3827991e (...fix...not being able to remove try compile code,
2008-03-26) introduced a loop of RemoveFile attempts to overcome
anti-virus locks on recently created try_compile executables. Fix the
logic in this loop to work when the file is already missing.
Bill Hoffman
Brad King
KWSys Robot
Clinton Stimpson
David Cole
Ben Boeckel
Rolf Eike Beer
Alex Neundorf
Eric NOULARD