| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
This may help statistically detect implicit dependencies among unit
tests while running in parallel.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We replace "/MD" with ifort-specific flags as follows:
/MD -> /threads /libs:dll
/MDd -> /threads /libs:dll /dbglibs
We also enable the "/MD" equivalent for all Fortran configurations.
Previously multithreaded dll runtimes were used for release builds and
threaded static runtimes for debug builds. For mixed Fortran C/C++
projects, this led to link warnings for Debug but not for Release.
See issue #8744.
|
| |
|
|
|
|
|
|
|
| |
The commit "Test per-config OUTPUT_DIRECTORY properties" added this test
with a find_library() call in a CMake script, which requires an explicit
list of possible library prefixes and suffixes. This commit adds more
suffixes to match the libraries built on HP, MinGW, and Cygwin.
|
| |
|
| |
|
| |
|
|
|
|
| |
build on dashmacmini2 might have enough time to complete successfully. Use CMAKE_LONG_TEST_TIMEOUT instead of a hard-coded number for the test TIMEOUT property so that a calling script may adjust it by setting a higher CTEST_TEST_TIMEOUT value.
|
|
|
|
| |
build on dashmacmini2 might have enough time to complete successfully. Allow for up to 3 hours. After measuring successful runs for a few weeks, perhaps we can use a lower value.
|
|
|
|
| |
was installed on those machines to increase coverage. Do not add install rules with absolute paths when makensis is going to be used to build an installer.
|
| |
|
| |
|
|
|
|
|
|
|
| |
We test (ARCHIVE|LIBRARY|RUNTIME)_OUTPUT_DIRECTORY_<CONFIG> properties
by building COnly as a subdirectory and setting the properties to put
its files in specific locations. We build an executable that verifies
the targets actually appear where expected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We create per-configuration target properties to specify ARCHIVE,
LIBRARY, and RUNTIME output directories. The properties override the
generic properties for the <CONFIG> configuration:
ARCHIVE_OUTPUT_DIRECTORY -> ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
LIBRARY_OUTPUT_DIRECTORY -> LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
RUNTIME_OUTPUT_DIRECTORY -> RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
For multi-configuration generators, the per-configuration subdirectory
normally appended to the generic output directory is not added to the
configuration-specific property values. This allows projects to set the
exact location at which binaries will be placed for each configuration.
See issue #9163.
|
|
|
|
|
| |
The documentation of (ARCHIVE|LIBRARY|RUNTIME)_OUTPUT_DIRECTORY was
duplicated. We consolidate it using a macro.
|
|
|
|
|
|
|
| |
VS 6 forgets to create the output directory for a static library if it
differs from the intermediate files directory. We work around this VS
bug by creating a pre-link event on the library target to make the
directory.
|
|
|
|
|
|
|
| |
This commit removes use of configuration-less cmTarget::GetDirectory()
by the VS 6 generator (except for compatibility with user templates).
We replace OUTPUT_DIRECTORY_<CONFIG> tokens in the templates using the
per-configuration result of cmTarget::GetDirectory(config).
|
|
|
|
|
| |
The dependency-helper makefiles should not have per-configuration names
for Xcode <= 2.0. Older Xcodes do not support multiple configurations.
|
|
|
|
|
|
| |
The try_compile() command's COPY_FILE option should not try to actually
copy the file if it cannot be found. Some C runtime library's fopen
cannot handle an empty file name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the Xcode generator set SYMROOT to be the target output
directory. This told Xcode to put the "<proj>.build" directory in the
output path too.
This commit sets SYMROOT, CONFIGURATION_BUILD_DIR, and OBJROOT to put
intermediate files in the build directory corresponding to the source
directory that created each target. This is more consistent with the VS
IDE generators. Now only the build output files (actual targets) go to
the target output directory.
|
|
|
|
|
| |
The commit "Fix if() command and CMP0012 OLD/NEW behavior" introduced an
unreachable 'break' after 'return' in a switch statement. We remove it.
|
|
|
|
|
|
| |
The commit "Disable Intel CRT deprecation warnings" broke the logic that
disabled MS's CRT deprecation warnings. This fixes the logic to disable
the warnings for both MSVC and Intel.
|
| |
|
| |
|
|
|
|
|
| |
This commit adds a CMake.ELF test to exercise cmELF and file(RPATH_*).
We test all combinations of 32/64-bit and LSB/MSB binaries.
|
|
|
|
| |
try to process NOT FOUND rather than an empty string when MPIEXEC is not found.
|
| |
|
|
|
|
| |
for mpi components (include,lib,bin) using a single set of search paths instead of seperately mainted lists of paths for each.
|
|
|
|
| |
during the CPackComponents test. The purpose of each is to increase coverage of cmake.cxx.
|
|
|
|
|
| |
This commit disables or fixes some warnings in the 'cmtar' utility
produced by the Intel compiler on Windows.
|
|
|
|
|
|
| |
The Intel Compiler for Windows uses the MS runtime library which
deprecates many C functions. We define _CRT_SECURE_NO_DEPRECATE and
_CRT_NONSTDC_NO_DEPRECATE to disable the deprecation warnings.
|
| |
|
|
|
|
| |
bug #9753)
|
|
|
|
|
|
|
| |
The BuildDepends test exercises incremental linking with MSVC and Intel
tools on Windows. In some cases the Intel compiler creates objects that
cause the MS linker it invokes to crash during incremental linking. We
avoid the problem for this test by disabling incremental linking.
|
|
|
|
|
| |
The Intel Fortran compiler needs options '-i_dynamic' and '-nofor_main'
to create shared libraries on Linux (for at least one architecture).
|
| |
|
|
|
|
|
|
| |
We introduce the "CMake.If" test to try out conversion of constants and
variables to boolean values in the if() command. We cover both OLD and
NEW behavior for policy CMP0012.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit "modified the if command to address bug 9123 some" changed
the if() command behavior with respect to named boolean constants. It
introduced policy CMP0012 to provide compatibility. However, it also
changed behavior with respect to numbers (like '2') but did not cover
the change with the policy. Also, the behavior it created for numbers
is confusing ('2' is false).
This commit teaches if() to recognize numbers again, and treats them
like the C language does in terms of boolean conversion. We also fix
the CMP0012 check to trigger in all cases where the result of boolean
coersion differs from that produced by CMake 2.6.4.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The if() command reports its arguments at the beginning of some error
messages. Originally it reported the un-expanded form of the arguments
because in ancient CMake versions no context information was available.
Now it is more useful to see the real arguments, which may be mentioned
in the main error message. Since full context information is now
available, users can refer back to the source if they need to see the
unexpanded form of the arguments.
For example, the code
set(regex "++")
if("x" MATCHES "${regex}")
endif()
now produces the message
if given arguments:
"x" "MATCHES" "++"
Regular expression "++" cannot compile
instead of
if given arguments
"x" MATCHES "${regex}"
Regular expression "++" cannot compile
|
| |
|
| |
|
|
|
|
| |
cmake generated build tree. Theoretically, each generation run with exactly the same arguments should be identical to the previous generation... Practically, there are differences. This is a tool to help us measure those differences. For now, the test always succeeds. Eventually, we may add the code to make it fail when there are differences.
|
| |
|
|
|
|
| |
not use auto_ptr on a new [] allocation because auto_ptr does not use delete [].
|