This adds another cast to avoid pointer conversion warnings.
Unfortunately C does not recognize implicit conversions that add
cv-qualifiers as well as C++ does.
The commit "Do not compute link language for LOCATION" was wrong. The
variables
CMAKE_STATIC_LIBRARY_PREFIX_Java
CMAKE_STATIC_LIBRARY_SUFFIX_Java
are used for building Java .jar files. This commit re-enables the
feature and documents the variables:
CMAKE_EXECUTABLE_SUFFIX_<LANG>
CMAKE_IMPORT_LIBRARY_PREFIX_<LANG>
CMAKE_IMPORT_LIBRARY_SUFFIX_<LANG>
CMAKE_SHARED_LIBRARY_PREFIX_<LANG>
CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>
CMAKE_SHARED_MODULE_PREFIX_<LANG>
CMAKE_SHARED_MODULE_SUFFIX_<LANG>
CMAKE_STATIC_LIBRARY_PREFIX_<LANG>
CMAKE_STATIC_LIBRARY_SUFFIX_<LANG>
Instead of making separate, repetitive entries for the _<LANG> variable
documentation, we just mention the per-language name in the text of the
platform-wide variable documentation. Internally we keep undocumented
definitions of these properties to satisfy CMAKE_STRICT mode.
This passes the build configuration to most GetLinkerLanguage calls. In
the future the linker language will account for targets linked in each
configuration.
This simplifies computation of the lastKnownFileType attribute for
header files in Xcode projects. We now use a fixed mapping from
header file extension to attribute value. The value is just a hint to
the Xcode editor, so computing the target linker language is overkill.
The LOCATION property requires the full file name of a target to be
computed. Previously we computed the linker language for a target to
look up variables such as CMAKE_SHARED_LIBRARY_SUFFIX_<LANG>. This led
to locating all the source files immediately instead of delaying the
search to generation time. In the future even more computation will be
needed to get the linker language, so it is better to avoid it.
The _<LANG> versions of these variables are undocumented, not set in any
platform file we provide, and do not produce hits in google. This
change just removes the unused feature outright.
The new method centralizes loops that process raw OriginalLinkLibraries
to extract the link implementation (libraries linked into the target)
for each configuration. Results are computed on demand and then cached.
This simplifies link interface computation because the default case
trivially copies the link implementation.
These member structures are accessed only in the cmTarget implementation
so they do not need to be defined in the header. This cleanup also aids
Visual Studio 6 in compiling them.
The config-to-interface map in cmTarget should use case-insensitive
configuration names. The change avoids repeating work if the given
configuration has a different case than one already computed.
This fixes a dumb logic error introduced by the centralization of link
interface computation. It prevented link directories from alternate
configurations from getting listed by the OLD behavior of CMP0003 for
targets linked as transitive dependencies.
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.
When LINK_INTERFACE_LIBRARIES is not set we use the link implementation
to implicitly define the link interface. These changes centralize the
decision so that all linkable targets internally have a link interface.
This moves code implementing policy CMP0004 into cmTarget::CheckCMP0004.
The implementation is slightly simpler and can be re-used outside of
cmComputeLinkDepends.
This fixes cmTarget::GetLinkInterface to compute and return the link
interface in an exception-safe manner. We manage the link interface
returned by cmTarget::ComputeLinkInterface using auto_ptr.
This teaches the makefile generators to always pass the configuration
name to the cmTarget::GetDirectory method. Later this will allow
per-configuration target output directories, and it cleans up use of the
current API.
This creates cmTarget::GetOutputInfo to compute, cache, and lookup
target output directory information on a per-configuration basis. It
avoids re-computing the information every time it is needed.
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.
This member stores the build configuration for which Makefiles are being
generated. It saves repeated lookup of the equivalent member from
cmLocalUnixMakefileGenerator3, making code shorter and more readable.
Previously tests marked with WILL_FAIL have been reported by CTest as
...............***Failed - supposed to fail
when they correctly failed. Now we just report ".....Passed" because
there is no reason to draw attention to something that works as
expected.
Xcode 2.0 and below supported only one configuration, but 2.1 and above
support multiple configurations. In projects for the latter version we
have been generating a "global" set of buildSettings for each target in
addition to the per-configuration settings. These global settings are
not used by Xcode 2.1 and above, so we should not generate them.
The cmGlobalXCodeGenerator::CreateBuildSettings had the three arguments
productName, productType, and fileType that returned information used by only
one of the call sites. This change refactors that information into separate
methods named accordingly.
Previously we named Xcode targets using the output file name from one of the
configurations. This is not very friendly, especially because it changes with
CMAKE_BUILD_TYPE. Instead we should use the original logical target names for
the Xcode target names. This is also consistent with the way the other IDE
generators work.
CMake previously generated Xcode project files labeled as 2.4-compatible
by recent versions of Xcode (3.0 and 3.1). It is better to generate
native Xcode 3.0 and 3.1 projects. In particular, this can improve
build times by using the "Build independent targets in parallel"
feature.
Patch from Doug Gregor. See issue #9216.
files of the project, i.e. there is now a "CMake Files" folder additionally
to the "Sources", "Headers" and "Others" folders which already existed.
Patch by Daniel Teske.
Alex
This cleans up the Makefile generator's progress rule code. Instead of
keeping every cmMakefileTargetGenerator instance alive to generate
progress, we keep only the information necessary in a single table.
This approach keeps most of the code in cmGlobalUnixMakefileGenerator3,
thus simplifying its public interface.
The TortoiseCVS version of cvs.exe includes the '.exe' in cvs update
messages for files removed from the repository. This change accounts
for it in the regular expressions that match such lines. Now removed
files are properly reported by ctest_update() when using TortoiseCVS.
This fixes the CMP0012 description to have a one-line summary in the
'brief' section and the rest of the explanation in the 'full' section.
It makes the warning message shorter and improves formatting of the
policy documentation, especially in the HTML pages. The convention is
already used by all other policies.
Errors and warnings from the if() command always display the argument
list given to the command followed by an explanation of the problem.
This moves the argument list into a pre-formatted block and follows it
with a paragraph-form explanation. The result looks cleaner.
In CMake 2.6.3 and below we silently accepted duplicate build
directories whose build files would then conflict. At first this was
considured purely a bug that confused beginners but would not be used in
a real project. In CMake 2.6.4 we explicitly made it an error.
However, some real projects took advantage of this as a "feature" and
got lucky that the subtle build errors it can cause did not occur.
Therefore we need a policy to deal with the case more gracefully.
See issue #9173.
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.
This moves creation of an executable's import library directory in VS
projects from the pre-build step to the pre-link step. It makes sense
to create the directory at the last moment.
In VS 7,8,9 executable targets we generate a build event to create the
output directory for the import library in case the executable marks
symbols with dllexport (VS forgets to create this directory). This
generalizes computation of the custom command line to support future use
with other VS versions.
This teaches the define_property command signature to accept multiple
arguments after the BRIEF_DOCS and FULL_DOCS keywords. We append the
arguments together, making specification of long documentation easier.
If an executable marks symbols with __declspec(dllexport) then VS
creates an import library for it. However, it forgets to create the
directory that will contain the import library if it is different from
the location of the executable. We work around this VS bug by creating
a pre-build event on the executable target to make the directory.
In cmLocalVisualStudio7Generator 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.
In Release builds the Borland compiler warns about code in its own
system headers. This blocks the warnings by disabling them where the
headers are included.
This replaces the Fortran dependency parser source's custom strcasecmp
implementation with one from KWSys String. It removes duplicate code
and avoids a Borland warning about inlining functions with 'while'.
The KWSys String implementation of strcasecmp initialized 'result'
immediately before assigning to it. Borland produces a warning in this
case, so this commit removes the extra initialization.
The fix for issue #9130 appends ':' to the end of the build-tree RPATH
unconditionally. This changes the fix to add ':' only when the RPATH is
not empty so that we do not create a build-tree RPATH with just ':'. An
empty RPATH produces no string at all, so there is no chance of merging
with a symbol name anyway.
We've chosen to drop our default dependence on xmlrpc. Thus we disable
the corresponding CTest submission method and remove the sources for
building xmlrpc locally. Users can re-enable the method by setting the
CTEST_USE_XMLRPC option to use a system-installed xmlrpc library.
In cmXMLParser::ReportXmlParseError we were accidentally passing a value
of type 'XML_Parser*' to expat methods instead of 'XML_Parser'. It was
not caught because XML_Parser was just 'void*' in the cmexpat version.
Newer system-installed expat versions catch the error because XML_Parser
is now a pointer to a real type. This correct the type.
In ELF binaries the .dynstr string table is used both for the RPATH
string and for program symbols. If a symbol name happens to match the
end of the build-tree RPATH string the linker is allowed to merge the
symbols.
We must not allow this when the RPATH string will be replaced during
installation because it will mangle the symbol. Therefore we always pad
the end of the build-tree RPATH with ':' if it will be replaced. Tools
tend not to use ':' at the end of symbol names, so it is unlikely to
conflict. See issue #9130.
This adds the Modules/Platform/OpenVMS.cmake platform file for OpenVMS.
We just use Unix-like rules to work with the GNV compiler front-end.
A problem with process execution currently prevents CMake link scripts
from working, so we avoid using them.
The VMS posix path emulation does not handle multiple '.' characters in
file names in all cases. This avoids adding extra '.'s to file and
directory names for target directories and generated files.
This teaches ConvertToUnixSlashes to convert VMS paths into posix-style
paths. We also set the DECC$FILENAME_UNIX_ONLY feature so the process
always sees posix-style paths on disk.
The Compaq compiler's std::unique algorithm followed by deletion of the
extra elements seems to crash. For now we'll accept the duplicate
dependencies on this platform.
This achieves basic process execution on OpenVMS. We use work-arounds
for different fork()/exec() behavior and a lack of select().
VMS emulates fork/exec using setjmp/longjmp to evaluate the child and
parent return cases from fork. Therefore both must be invoked from the
same function.
Since select() works only for sockets we use the BeOS-style polling
implementation. However, non-blocking reads on empty pipes cannot be
distinguished easily from the last read on a closed pipe. Therefore we
identify end of data by an empty read after the child terminates.
The Compaq compiler (on VMS) includes 'String.c' in source files that
use the stl string while looking for template definitions. This was the
true cause of double-inclusion of the 'kwsysPrivate.h' header. We work
around the problem by conditionally compiling the entire source file on
a condition only true when really building the source.
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
Brad King
David Cole
Alexander Neundorf
Bill Hoffman
Clinton Stimpson
Ken Martin
Francois Bertel
Dave Partyka