| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As INTERFACE_COMPILE_DEFINITIONS are now possible, we can have
situations like this:
add_library(foo ...)
add_library(bar ...)
target_link_libraries(foo bar)
target_compile_definitions(bar INTERFACE SOME_DEF)
The INTERFACE_COMPILE_DEFINITIONS of bar determine how foo should be
compiled, and if they change, foo should be rebuilt.
Additionally, as of commit d1446ca7 (Append the COMPILE_DEFINITIONS
from the Makefile to all targets., 2012-09-17), we don't need to
read definitions from the makefile if we read them from the target,
so also de-duplicate the cached info.
The DependInfo for INTERFACE_INCLUDE_DIRECTORIES is already handled
correctly.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit c8ef6430 (Allow directory names containing '=' and warn if
necessary, 2012-02-06) we allow directories with '=' instead of
rejecting them as was previously done since commit 8704525f (Reject
directory names containing '=', 2011-01-14). However, we did not warn
in all cases that '=' may cause failure, such as when it appears on the
right-hand side of a dependency line.
Both commits above were made assuming that '=' cannot be escaped in Make
syntax, but it can be achieved with a variable:
EQUALS = =
left$(EQUALS)side : right$(EQUALS)side
Use this approach to escape '=' in dependency lines, thus supporting
the character in paths.
All our tests now pass when CMake is built in source and build trees
both containing '=', except for the "OutOfSource" test. It fails in
its coverage of the obscure "OutOfBinary" test case where part of the
build tree is located outside the main build tree of the test. The
reason is that CMake must invoke a command like
$(MAKE) -f /path/with=sign/build.make /path/with=sign/somefile
but the make tool interprets the last argument as a variable assignment.
This is an acceptable limitation, since the case is so obscure, in
exchange for supporting '=' cleanly otherwise.
|
|
|
|
|
|
| |
Treat OBJECT libraries as STATIC libraries but leave out the archive
step. The object files will be left behind for reference by other
targets later.
|
|
|
|
|
|
|
| |
Add a virtual cmGlobalGenerator::ComputeTargetObjects method invoked
during cmGeneratorTarget construction. Implement it in the Makefile
generator to pre-compute all object file names for each target. Use
the results during generation instead of re-computing it later.
|
|\ |
|
| |
| |
| |
| |
| | |
Make cmLocalUnixMakefileGenerator3::LocalObjectInfo private and add
cmLocalUnixMakefileGenerator3::AddLocalObjectFile to create entries.
|
| |
| |
| |
| |
| |
| |
| | |
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
|
|/
|
|
|
|
|
|
|
| |
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
|
|\
| |
| |
| |
| | |
c8ef643 Allow directory names containing '=' and warn if necessary (#12934)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The approach taken by commit 8704525f (Reject directory names containing
'=', 2011-01-14) was perhaps too heavy-handed for avoiding the obscure
cases when '=' in the path fails due to limitations of Make syntax.
Only two CMake tests:
LinkDirectory
OutOfSource
fail when the path contains '=' and they cover obscure cases. Instead
of rejecting such paths outright just warn when the problem may occur.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Now also CMAKE_ASM_INCLUDE_PATH is written into
CMakeDirectoryInformation.cmake, which is necessary to make
the dependency scanning for included files work.
Alex
|
|\ \
| | |
| | |
| | |
| | | |
6d51f5f Fix typo.
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Watcom WMake tool has trouble running commands in paths that have
parentheses. We already convert most commands to a shortpath for Watcom
if the path contains a space, but the use of $(CMAKE_COMMAND) hides the
true path from that conversion. Factor the shortpath conversion code
out into a new ConvertShellCommand method. Teach it to convert paths
that contain parentheses as well as spaces. Use the new method to
convert the value of $(CMAKE_COMMAND) and other helper variables.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Files for the ASM language are those assembler files which are processed
by the C/CXX compiler, and they may contain preprocessor directives, so
run the C dependency scanner also on them.
Alex
|
| |
| |
| |
| |
| |
| |
| | |
If you had a + in the name of a target with nmake, it created a variable
in the makefile that used + in its name, which is not allowed by nmake.
To make the implementation easier, + is now not allowed for any make
generators as part of a variable name.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The workaround added by commit 7e92f0b4 (Hack to make echo command work
properly in mingw32-make, 2006-10-05) and updated by commit 69356d8a
(Juse use cmake -E echo instead of the native echo, 2006-10-13) no
longer seems necessary with modern mingw32-make. Furthermore it slows
performance due to the time spent loading a cmake process instead of
plain echo.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The parent commit assumed that "cd /d" would work in all Windows shells.
While all modern versions of windows have shells that support it, the
shells used by NMake and Borland make do not. Borland make does not
seem to even support changing drive letters with "d:". Just revert the
feature for all make tools except MinGW where the shell is known to
support this feature.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Teach cmLocalUnixMakefileGenerator3::CreateCDCommand to change working
directories for make tools using a Windows shell using "cd /d" instead
of just "cd". This tells the shell to change the current drive letter
as well as the working directory on that drive.
Commit abaa0267 (When the working directory for a custom command is on
another drive..., 2007-12-17) fixed the same problem for VS IDE
generators as reported by issue #6150.
|
|/
|
|
|
|
| |
Create platform option CMAKE_<lang>_USE_RESPONSE_FILE_FOR_INCLUDES to
enable use of response files for passing the list of include directories
to compiler command lines.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Allow file-level custom command dependencies to be skipped.
|
|
|
|
|
|
|
|
|
| |
Instead of enforcing verbose makefile, now the generated build command
includes "VERBOSE=1" so the output will be verbose when building in
C::B.
Also removed the now unused setForceVerboseMakefiles().
Alex
|
|
|
|
| |
Alex
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The solution seems hackish, but it works: for
NMake only, prepend a no-op command before each
real command that begins with ".
This is really a work-around for an NMake problem.
When a command begins with ", nmake truncates the
first argument to the command after the first :
in that arg. It has a parsing problem.
Workaround..., hackish..., but it should solve
the issue for #9963 and its related friends.
Also, modify the CustomCommand test to replicate
the problem reported in issue #9963. Before the
NMake specific code change, the test failed.
Now, it passes. Ahhhhhh.
|
|
|
|
|
|
|
|
| |
If there is a .bat or .cmd file used as a custom command
then the Borland Makefiles generator (specifically) requires
using the "call " syntax before the name of the .bat or .cmd
file. This fix applies to all Makefile based generators where
WindowsShell is true.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now only the dependencies for the file where the dependencies actually may
have changed are rescanned, before that this was done for all source files
even if only one source file had changed.
This reduces e.g. on my machine the time for scanning the dependencies
of kdelibs/khtml/ when only one file (khtml_global.cpp) has changed from
around 7.5 seconds to 1.2 seconds.
The tests succeed, it does what I expected it to do on kdelibs, and Brad
also reviewed the patch, so I think it should be ok.
Alex
|
|
|
|
|
|
|
|
| |
If CMakeDirectoryInformation.cmake is newer than depend.internal the include
directories may have changed, so dependencies need to be scanned again.
Ok by Brad.
Alex
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change all targets were displayed in the top level directory of
the project. Now the targets are displayed in the correct directory.
The targets "clean" and "all" are now created in every subdirectory.
Also now the targets for just compiling one file, preprocessing one file,
assembling one file are are created for Eclipse.
Additionally all targets get a prefix now in eclipse, so that they are
sorted in a way which makes sense (global targets first, then executable and
libraries, then object files, then preprocessed, then assembly). Also
this prefix gives the user a hint what the target is, i.e. whether it's a
library or an executable or something else.
Alex
|
|
|
|
|
|
|
|
| |
Generated makefiles for try-compile projects should never use color
output. On MSYS the color escapes end up in the try-compile output text
because there is no way to identify whether the output is going to a
color-capable terminal. Instead we should just always skip color for
try-compile projects.
|
|
|
|
|
| |
This passes the build configuration to cmTarget methods IsChrpathUsed
and NeedRelinkBeforeInstall. Later these methods will use the value.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This shell does not exist on VMS, so we leave it out.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
|
|
|
|
|
|
| |
This defines make rule substitutions <LANGUAGE>, <TARGET_NAME>,
<TARGET_TYPE>, and <OUTPUT>. They will be useful for RULE_LAUNCH_*
property values.
|
|
|
|
|
|
|
| |
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
|
|
|
|
|
|
| |
This gives the cmTarget instance for which custom command rules are
being generated to cmLocalUnixMakefileGenerator3::AppendCustomCommands.
It will be useful in the future.
|
|
|
|
|
|
| |
DOT com, QtCreator developer
Alex
|
|
|
|
|
|
|
|
|
|
| |
This simplifies computation of custom command rule hashes to hash
content exactly chosen as the custom commands are generated.
Unfortunately this will change the hashes of existing build trees from
earlier CMake versions, but this is not a big deal. The change is
necessary so that in the future we can make optional adjustments to
custom command lines at generate time without changing the hashes every
time the option is changed.
|
|
|
|
|
|
| |
When computing the maximum length full path to the build directory under
which object files will be placed, pass the actual path instead of just
its length. This will be useful for error message generation.
|
|
|
|
|
|
|
| |
These changes refactor cmLocalGenerator methods Convert and
ConvertToOutputForExisting to support references inside the build tree
using relative paths. After this commit, all tests pass with Makefile
generators when relative paths are enabled by default. See issue #7779.
|
|
|
|
|
|
| |
The CMAKE_EDIT_COMMAND make variable need not be constructed with
ConvertToOutputForExisting. The CMAKE_COMMAND variable works fine
without it.
|