summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Detect and set Unicode character set in VS 10Brad King2009-10-232-11/+57
| | | | | | | | This commit teaches the VS 10 generator to detect the -D_UNICODE option in preprocessor definitions and set the CharacterSet attribute to the value 'Unicode'. This was already done for other VS IDE versions. See issue #9769
* Always set OutputPath in VS 10 projectsBrad King2009-10-231-4/+9
| | | | | | | | | | | The default $(OutDir)$(TargetName)$(TargetExt) for this value works in most cases because we set the three properties. However, if the target property PREFIX contains a path component (not documented but happens to work in other VS generators) we drop it from TargetName and do not put it in OutDir either. This commit corrects the resulting path by setting the OutputPath property explicitly with the full path. See issue #9768.
* Add support for the g95 Fortran compilerBrad King2009-10-232-0/+9
| | | | | | | | | | This commit teaches CMake about the g95 compiler from http://www.g95.org We use 'G95' as the compiler id string, and add some basic flags. See issue #9241.
* Test all target types in FortranBrad King2009-10-234-3/+19
| | | | | This teaches the Fortran test to try all basic target types (archive, shared lib, exe) with Fortran-only sources.
* Fix line-too-long style violationsBrad King2009-10-234-4/+8
| | | | | The commit "Define per-target OSX_ARCHITECTURES property" introduced some long lines. This wraps them into multiple shorter lines.
* KWSys Nightly Date StampKWSys Robot2009-10-231-1/+1
|
* Add Xcode file association for FortranBrad King2009-10-221-0/+4
| | | | | | | Intel Fortran on Mac OS X enables Fortran support in Xcode. This commit teaches CMake to associate Fortran sources properly in Xcode projects. See issue #9739.
* Fix VS 10 flag table for precompiled headersBrad King2009-10-221-3/+10
| | | | | | | | | | The VS 10 flag table generation script did not produce correct entries for precompiled header flags. Since precompiled header flag translation requires multiple entries cooperating in a certain order, it is not worth the time to make the generation script work automatically. This commit manually adds the proper entries. See issue #9753.
* Fix VS 10 .sln files for Windows ExplorerBrad King2009-10-221-1/+1
| | | | | | | This commit fixes generated .sln files so they open VS 2010 correctly when double-clicked in Windows Explorer. See issue #9758.
* Fix Microsoft.Cpp.$(Platform).user.props in VS10b2Brad King2009-10-221-6/+4
| | | | | | | MS changed the location of the Microsoft.Cpp.$(Platform).user.props file. This commit teaches the VS 10 generator about the new location. See issue #9759.
* Add test of all cmake -G generators. Ignore any errors from this as not all ↵David Cole2009-10-222-0/+109
| | | | generators are expected to be usable on all machines. Help to increase coverage of the various generators and cmake.cxx itself.
* Fix up download a bit, better error checking and uses of long not double for ↵Bill Hoffman2009-10-222-38/+125
| | | | timeout as curl needs, bug# 9748
* More verbose BuildDepends test outputBrad King2009-10-221-2/+4
| | | | | We teach BuildDepends to always print the output from each try_compile. This may make debugging easier.
* WIP: VS 10 Win64 generatorBrad King2009-10-229-14/+98
| | | | See issue #9754.
* Fix for bug#9686 convert java_home to a cmake path before using.Bill Hoffman2009-10-221-5/+8
|
* KWSys Nightly Date StampKWSys Robot2009-10-221-1/+1
|
* fix for bug# 9751, add check for MSVC10Bill Hoffman2009-10-221-0/+2
|
* Fix for bugs #9756, #9690 and #9755, header files were not included, and ↵Bill Hoffman2009-10-221-8/+25
| | | | link_directories we incorrect
* Add license.Bill Hoffman2009-10-211-0/+14
|
* Clean up output a bit.Bill Hoffman2009-10-211-1/+3
|
* Add a module to test an install tree to verify that the MS CRT version is ↵Bill Hoffman2009-10-211-0/+4
| | | | correct.
* Add a module to test an install tree to verify that the MS CRT version is ↵Bill Hoffman2009-10-211-0/+91
| | | | correct.
* Use copies for versioned names on WindowsBrad King2009-10-211-0/+4
| | | | | | | | | | | | | | | Versioned UNIX libraries and executables produce multiple names for a single target using one of cmake -E cmake_symlink_library cmake -E cmake_symlink_executable to create symlinks to the real file for the extra names. However, when cross-compiling from Windows to Linux we cannot create symlinks. This commit teaches CMake to make copies instead of symbolic links when running on windows. While this approach does not produce exactly what Linux wants to see, at least the build will complete and the binary will run on the target system. See issue #9171.
* Tweak all files during target installationBrad King2009-10-212-48/+104
| | | | | | | | | | | | | During installation of a target we generate "tweak" rules to update the installed file (RPATH, strip, ranlib, etc.). However, some targets install multiple files, such as the versioned names of a shared library. Previously the extra files for a target have always been symbolic links, but for cross-compiling from Windows to UNIX they may need to be copies. This commit teaches the generated install scripts to loop over all files installed for the target to apply tweaks to those that are not symlinks. See issue #9171.
* Add IS_SYMLINK test to if commandBrad King2009-10-212-0/+10
|
* Compute install destination for all target filesBrad King2009-10-211-70/+70
| | | | | | | | | In cmInstallTargetGenerator::GenerateScriptForConfig we were computing the full 'from' paths for all target files to be installed, but only computing a 'to' path for the "main" target file. This commit teaches the method to compute both 'from' and 'to' paths for every target file to be installed. The result is cleaner, easier to follow, and will allow installation tweaks to be added later on all target files.
* Factor out "cmake -E cmake_symlink_*" codeBrad King2009-10-212-51/+61
| | | | | | | | | | | | | | We factor the implementation of cmake -E cmake_symlink_library cmake -E cmake_symlink_executable out of cmake::ExecuteCMakeCommand into methods cmake::SymlinkLibrary cmake::SymlinkExecutable plus a helper method cmake::SymlinkInternal.
* Simplify 'strip' and 'ranlib' install tweak codeBrad King2009-10-212-8/+4
| | | | | | The cmInstallTargetGenerator methods AddStripRule and AddRanlibRule do not need the target type argument. They can simply use the type of the target for which the generator instance was created.
* Test OSX_ARCHITECTURES target propertyBrad King2009-10-214-2/+34
| | | | | | | We test the property with a project that fails to link due to an architecture mismatch between an executable and a static library. See issue #8725.
* Define per-target OSX_ARCHITECTURES propertyBrad King2009-10-218-25/+112
| | | | | | | | | | | The CMAKE_OSX_ARCHITECTURES variable works only as a global setting. This commit defines target properties OSX_ARCHITECTURES OSX_ARCHITECTURES_<CONFIG> to specify OS X architectures on a per-target and per-configuration basis. See issue #8725.
* Fix seg fault for empty ENV{} call bug #9747Bill Hoffman2009-10-211-1/+5
|
* KWSys Nightly Date StampKWSys Robot2009-10-211-1/+1
|
* Better fix for finding the MSBuild that matches the VS 10 install.Bill Hoffman2009-10-201-4/+2
|
* Add search path for VS 10 beta 2 MSBuild.Bill Hoffman2009-10-201-0/+2
|
* make testing the CodeBlocks and Eclipse generators easier by not requiring ↵Alexander Neundorf2009-10-202-4/+14
| | | | | | | | | | | | | the CMAKE_EDIT_COMMAND variable Both generators use the CMAKE_EDIT_COMMAND variable to determine whether they should add the edit_cache target, i.e. they don't add it if it's ccmake, since this does not work inside the output log view of Eclipse/Codeblocks. But instead of requiring the variable to be set they now check it for 0 and handle this appropriately. This should help Dave getting some testing for them :-) Alex
* Do not link library dependencies in VS solutionsBrad King2009-10-206-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | In VS 8 and greater this commit implements add_dependencies(myexe mylib) # depend without linking by adding the LinkLibraryDependencies="false" option to project files. Previously the above code would cause myexe to link to mylib in VS 8 and greater. This option prevents dependencies specified only in the solution from being linked. We already specify the real link library dependencies in the project files, and any project depending on this to link would not have worked in Makefile generators. We were already avoiding this problem in VS 7.1 and below by inserting intermediate mylib_UTILITY targets. It was more important for those versions because if a static library depended on another library the librarian would copy the dependees into the depender! This is no longer the case with VS 8 and above so we do not need that workaround. See issue #9732.
* Fix failing test. Forgot to double quote last arg to STRING.David Cole2009-10-201-3/+3
|
* Add test of all available CPack generators. Add this test with the goal of ↵David Cole2009-10-204-1/+96
| | | | increasing coverage of the cpack source code, even/especially when the underlying packager tool is not installed. The test does not fail if there is a cpack problem with a certain generator. I expect some generators will fail on every machine running a CMake dashboard.
* Added a ctest add_subdirectory test which fails before my patch made earlier ↵Zach Mullen2009-10-206-0/+65
| | | | today.
* Ctest was broken for subdirs. Restored working directory state for tests so ↵Zach Mullen2009-10-201-0/+5
| | | | that their executables could be found.
* Fixes version detection using osg/Version on Mac OSX when OSG is installed ↵Philip Lowman2009-10-201-2/+8
| | | | | | as a framework Patch from rpavlik attached to issue #9714
* KWSys Nightly Date StampKWSys Robot2009-10-201-1/+1
|
* Avoid C++ linker language in VS Fortran projectBrad King2009-10-191-1/+2
| | | | | | | | | | | | | | | In Visual Studio project files we pass compiler flags to the whole target based on the linker language, which works for MS tools and combinations of C and C++. For the Intel Fortran plugin though the generated .vfproj files should never contain C or C++ options. We generate .vfproj files only for targets consisting only of Fortran code. Now that the linker language is computed transitively through linking it is possible that the linker language is C++ for an otherwise Fortran-only project. This commit forces Fortran as the linker language for the purpose of specifying target-wide flags in .vfproj files. See issue #9719.
* fix whitespace, so documentation is formatted properlyAlexander Neundorf2009-10-191-15/+15
| | | | Alex
* fix two more icpc warnings, ok by Brad (float compared for equality, unused ↵Alexander Neundorf2009-10-191-2/+2
| | | | | | variable) Alex
* Avoid duplicate ZERO_CHECK in VS solutionsBrad King2009-10-194-122/+107
| | | | | | | | | | | | The commit "Avoid non-root copies of root-only targets" moved the check for root-only targets into cmGlobalGenerator::GetTargetSets to avoid adding multiple ALL_BUILD targets to the "original" target set. This approach did not work for ZERO_CHECK targets though because those are pulled in by dependency analysis. Instead we eliminate duplicate ZERO_CHECK targets altogether and refer to a single one from all solution files. This cleans up VS 10 project file references to ZERO_CHECK targets anyway.
* Fixed bug 8319, search for the Python shared library in the standard locations.Marcus Hanwell2009-10-191-2/+0
|
* KWSys Nightly Date StampKWSys Robot2009-10-191-1/+1
|
* KWSys Nightly Date StampKWSys Robot2009-10-181-1/+1
|
* Remove the rpath_remove_file_is_not_executable test case. It fails on ↵David Cole2009-10-172-3/+3
| | | | Windows, but passes on Linux. Put back later after addressing inconsistency.
generated by cgit v0.12 at 2025-01-06 10:50:38 (GMT)