In cmGlobalGenerator we use cmComputeTargetDepends to construct a safe,
non-circular set of inter-target dependencies. This change enables use
of the results by the Xcode generator. It also removes a lot of old
code and another use of the old-style linking logic. See issue #7652.
A Mac OS X Framework should provide a Resources/Info.plist file
containing meta-data about the framework. This change generates a
default Info.plist for frameworks and provides an interface for users to
customize it.
This change cleans up the implementation of cmXCodeObject to avoid
un-escaping and re-escaping string values. There is no need to store
the string in escaped form. It can be escaped once when it is printed
out to the generated project file.
- The Info.plist file in app bundles should not be built.
- User-specified files such as foo.txt should not be built.
- Only files with a recognized language should be built,
just as in the Makefiles generators.
- See bug #7277.
- Generated Xcode projects for application bundles list the
CMake-generated Info.plist input file as a resource.
- The location of the input file was moved by a previous commit,
but the reference to it as a resource file was not updated.
- This change moves the file to CMakeFiles/<tgt>.dir/Info.plist
to give it a more intuitive name in the Xcode project.
- We also update the reference to point at the correct location.
- See bug #7277.
- The Xcode generator creates one Info.plist input file which is
converted at build time by Xcode and placed in the final bundle.
- The <CONFIG>_OUTPUT_NAME target property can place different content
for the exe name in Info.plist on a per-configuration basis.
- Instead of generating a per-config Info.plist input file just let
Xcode put the name in at build time using the $(EXECUTABLE_NAME) var.
- Place the built library in foo.framework/Versions/A/foo
- Do not create unused content symlinks (like PrivateHeaders)
- Do not use VERSION/SOVERSION properties for frameworks
- Make cmTarget::GetDirectory return by value
- Remove the foo.framework part from cmTarget::GetDirectory
- Correct install_name construction and conversion on install
- Fix MACOSX_PACKAGE_LOCATION under Xcode to use the
Versions/<version> directory for frameworks
- Update the Framework test to try these things
- Imported frameworks have the FRAMEWORK property set
- Added cmTarget::IsFrameworkOnApple method to simplify checks
- Also remove separate IMPORTED_ENABLE_EXPORTS property and just use ENABLE_EXPORTS since, like FRAMEWORK, it just represents the target type.
- Document FRAMEWORK keyword in INSTALL command.
- Updated IMPORTED_LOCATION property documentation for Frameworks
- Created cmExportFileGenerator hierarchy to implement export file generation
- Installed exports use per-config import files loaded by a central one.
- Include soname of shared libraries in import information
- Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands
- Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators
- Import files compute the installation prefix relative to their location when loaded
- Add mapping of importer configurations to importee configurations
- Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries
- Scope IMPORTED targets within directories to isolate them
- Place all properties created by import files in the IMPORTED namespace
- Document INSTALL(EXPORT) and EXPORT() commands.
- Document IMPORTED signature of add_executable and add_library
- Enable finding of imported targets in cmComputeLinkDepends
- This is purely an implementation improvement. No interface has changed.
- Create cmComputeLinkInformation class
- Move and re-implement logic from:
cmLocalGenerator::ComputeLinkInformation
cmOrderLinkDirectories
- Link libraries to targets with their full path (if it is known)
- Dirs specified with link_directories command still added with -L
- Make link type specific to library names without paths
(name libfoo.a without path becomes -Wl,-Bstatic -lfoo)
- Make directory ordering specific to a runtime path computation feature
(look for conflicting SONAMEs instead of library names)
- Implement proper rpath support on HP-UX and AIX.
something like this:
ENABLE_LANGUAGE(ASM-ATT)
IF(CMAKE_ASM-ATT_COMPILER_WORKS)
... do assembler stufff
ELSE(CMAKE_ASM-ATT_COMPILER_WORKS)
... fallback to generic C/C++
ENDIF(CMAKE_ASM-ATT_COMPILER_WORKS)
Alex
CMake-SourceFile2-bp and CMake-SourceFile2-b-mp1 to trunk. This
commit is surrounded by tags CMake-SourceFile2-b-mp1-pre and
CMake-SourceFile2-b-mp1-post on the trunk.
The changes re-implement cmSourceFile and the use of it to allow
instances to be created much earlier. The use of cmSourceFileLocation
allows locating a source file referenced by a user to be much simpler
and more robust. The two SetName methods are no longer needed so some
duplicate code has been removed. The strange "SourceName" stuff is
gone. Code that created cmSourceFile instances on the stack and then
sent them to cmMakefile::AddSource has been simplified and converted
to getting cmSourceFile instances from cmMakefile. The CPluginAPI has
preserved the old API through a compatibility interface.
Source lists are gone. Targets now get real instances of cmSourceFile
right away instead of storing a list of strings until the final pass.
TraceVSDependencies has been re-written to avoid the use of
SourceName. It is now called TraceDependencies since it is not just
for VS. It is now implemented with a helper object which makes the
code simpler.
"imported" executable target. This can then be used e.g. with
ADD_CUSTOM_COMMAND() to generate stuff. It adds a second container for
"imported" targets, and FindTarget() now takes an additional argument bool
useImportedTargets to specify whether you also want to search in the
imported targets or only in the "normal" targets.
Alex
Brad King
Bill Hoffman
David Cole
Ken Martin
Alexander Neundorf