summaryrefslogtreecommitdiffstats
path: root/Help/generator
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'vs-default-platform'Brad King2019-04-221-1/+2
|\ | | | | | | | | | | | | db02be85a0 VS: Provide the default platform name to project code Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3246
| * VS: Provide the default platform name to project codeBrad King2019-04-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio generators based on `CMAKE_GENERATOR_PLATFORM` or some default. Prior to the VS 2019 generator, the default was always `Win32`. However, for the `Visual Studio 16 2019` generator, the default is based on the host platform. Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for use by project code. This is particularly useful in toolchain files because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so `CMAKE_VS_PLATFORM_NAME` is not yet known. Of course the toolchain file author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that will be used. Fixes: #19177
* | Merge topic 'ghs_os_dir'Brad King2019-04-081-1/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | a1e6b414b9 GHS: Update GHS_BSP_NAME processing 266dadf868 GHS: Print status message regarding GHS_OS_DIR Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3123
| * | GHS: Print status message regarding GHS_OS_DIRFred Baksik2019-03-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | -- Rename platform script so it runs before initial try_compile() in project() command. -- Fix incorrect variable name GHS_OS_DIR_OPTION -- Remove unnecessary ".*" from REGEX expression for GHS_CANDIDATE_OS_DIRS -- Forward GHS_OS_DIR_OPTION to try_compile() and preserve trailing whitespace of the variable.
* | | Help: Improve documentation formatingBartosz Kosiorek2019-04-0411-25/+28
|/ /
* | GHS: Add support for GHS Multi Generator in LinuxNaren Manimohan2019-03-211-2/+2
| |
* | Xcode: Require at least Xcode 5Gregor Jasny2019-02-161-3/+1
|/
* GHS: Document usage of GHS_NO_SOURCE_GROUP_FILEFred Baksik2019-02-081-0/+1
| | | | -- Also change variable name to CMAKE_GHS_NO_SOURCE_GROUP_FILE
* Xcode: deprecate support for Xcode 4Gregor Jasny2019-02-061-1/+3
|
* VS: Teach VS 2019 generator to select host tools matching host archBrad King2019-01-281-1/+2
| | | | | This generator is new so we can introduce the long-desired behavior of selecting ``host=x64`` tools by default on x64 hosts.
* VS: Add support for explicit 32-bit toolset selection via host=x86Brad King2019-01-285-3/+16
| | | | | Generalize the ``host=x64`` option in `CMAKE_GENERATOR_TOOLSET` to also support ``host=x86``.
* GHS: try_compile() now uses GHS platform variablesFred Baksik2019-01-161-1/+2
| | | | | | | -- Forward GHS platform variables to try_compile() CMAKE_TRY_COMPILE_PLATFORM_VARIABLES only worked for source signature try_compile() -- Update tests to no longer add GHS platform variables to try_compile() -- Avoid linker error in GhsMulti/GhsMultiCompilerOptions/CMakeLists.txt by building library
* GHS: Fix toolset selectionFred Baksik2019-01-161-4/+5
| | | | | | -- Allow -T to accept full or partial paths -- Use "C:/ghs" if GHS_TOOLSET_ROOT is empty string -- Put more information in error messages
* GHS: Integrity Application updatesFred Baksik2019-01-161-10/+19
| | | | | | | | | | | | | | | | | -- Check the property "ghs_integrity_app" on executables to set [INTEGRITY Application] If the property is not set then check if an integrate file is one of the source files (.int file). Dynamic Downloads that do not have an integrate file can use this property along with setting the compiler flag "-dynamic". -- Remove parsing for -dynamic flag; it is only used to print a comment The MULTI GUI will show if it is a Monolith or Dynamic Download application -- Use project references to specify which executables are part of the Integrity Application Usually Implicit Dependency Analysis will ensure that executable targets become part of the application. This does not work for Dynamic Download without integrate files. Use `add_dependencies(dd vas)` to mark that the vas target is part of dd target. -- Update file locations in the Integrate files.
* GHS: Place build system outputs per target output directivesFred Baksik2019-01-161-0/+3
| | | | | | | | | | | | | | -- Set output and object file locations -- Suffixes are no longer being forced but will now follow the target properties By default GHS tools have no suffix for executable files so CMAKE_EXECUTABLE_SUFFIX was changed to meet this behavior -- Remove #if 0 blocked out code; it has been replaced. Forcing the -relprog option has been removed from non-kernel executable targets. The default value of this option (if it is even available) is determined by the tool-chain for the specified target and platform (Some tool-chains default to -locatedprogram). The use of -relprog can have unexpected results as it cannot always produce a fully relocated executable. -- Clarify use of CMAKE_BUILD_TYPE to control build configuration
* VS: Add Visual Studio 16 2019 generatorBrad King2019-01-111-0/+49
| | | | | | | | | | | | Add this generator *without* support for specifying the target architecture in the generator name. cmake-gui will be taught to provide a field for this, and command-line builds can use -A. Also, teach this generator to select a default target architecture based on the host architecture. Fixes: #18689 Inspired-by: Egor Pugin <egor.pugin@gmail.com>
* Help: Document VS generator default platform selectionBrad King2019-01-106-0/+12
|
* Help: Suggest using -A to specify platform for VS generatorsBrad King2018-09-256-60/+119
| | | | | We already suggest `-T` for the toolset. Create a dedicated section for platform selection and suggest `-A`. Provide examples.
* Help: Describe the type of Visual Studio projects that can be generatedJean-Christophe Fillion-Robin2018-08-095-0/+30
| | | | | Issue: #17956 See-also: https://stackoverflow.com/questions/51647437/use-cmake-to-generate-visual-studio-python-projects/51666488
* GHS: Update default BSP nameFred Baksik2018-07-111-1/+4
| | | | | -- Use default value of sim<arch> if not user defined -- Also no reason to trim quotes or changes slashes; it is just a name not a path
* GHS: Update setting default OS location for Integrity platformsFred Baksik2018-07-111-1/+9
| | | | | | | -- Update how the latest OS is determined; scan the location GHS_OS_ROOT and sort it No longer use registry settings looking for installations The registry values are assigned in installation order for Green Hills tools not version order Filter out files from the list of directories (i.e if int1234.zip and int1234 are both in root folder)
* GHS: Set primary target using arch/platform values (or user specified value)Fred Baksik2018-07-111-0/+5
|
* GHS: Add platform selection supportFred Baksik2018-07-111-0/+5
|
* GHS: Add toolset selection supportFred Baksik2018-07-111-0/+9
| | | | | | | | | | | | | | | | -- Use the specified toolset located within GHS_TOOLSET_ROOT -- Update how the latest toolset is determined; scan the location GHS_TOOLSET_ROOT and sort it No longer use registry settings looking for installations The registry values are assigned in installation order for Green Hills tools not version order -- Update to use gbuild.exe from the proper toolset -- Clarify that CMAKE_MAKE_PROGRAM should not be set by user. -- Detect some toolset changes when regenerating project files This could occur if GHS_TOOLSET_ROOT was changed by user after the initial project generation This could occur if CMAKE_MAKE_PROGRAM was changed at the command line -- Use placeholder values for CMAKE_<LANG>_COMPILER The MULTI build system only uses gbuild to build a project gbuild uses the project file to determine which set of compilers to use based on target platform and architecture because compiler detection is skipped, placeholder values are used so that CMake does not complain
* GHS: Support ARM, PPC, 86 architecturesFred Baksik2018-07-071-0/+6
| | | | | | -- Update -A option to choose target architecture. -- Update commentary about which variables are used to control toolset and target settings -- Remove setting CMAKE_SYSTEM_PROCESSOR because the value is overwritten to be "" by subsequent CMAKE processing
* Drop Visual Studio 8 2005 generatorBrad King2018-04-021-20/+3
| | | | This generator has been deprecated since CMake 3.9. Remove it.
* Generators: remove KDevelop3 generatorAlex Neundorf2018-01-241-25/+0
| | | | | | | | | | The last KDevelop3 release was many years ago, in 2008 I think. I haven't seen or read about anybody using KDevelop 3 since a long time, so I think it can safely be removed from CMake. KDevelop 4 (first released in 2010) has its own proper CMake support now, independent from this generator. Alex
* VS: Select and save a VS 2017 instance persistentlyBrad King2017-10-191-7/+11
| | | | | | | | | | Visual Studio 2017 supports multiple instances installed on a single machine. We use the Visual Studio Installer tool to enumerate instances and select one. Once we select an instance for a given build tree, save the result in `CMAKE_GENERATOR_INSTANCE` so we can re-configure the tree with the same instance on future re-runs of CMake. Fixes: #17268
* CodeBlocks: add option to exclude external filesAlexandr (Sagrer) Gridnev2017-09-141-1/+5
| | | | | | | | | | | | Add variable `CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES` to optionally exclude files from outside the project root from the project file written by the CodeBlocks extra generator. This optionally restores logic that had been removed by commit v2.8.3~40^2 (CodeBlocks Generator: Do not omit files in the project file listing, 2010-10-05) in response to QTCREATORBUG-2250. Issue: #12110 Fixes: #17188
* VS: Choose VS 2017 instance via environment variableBrad King2017-07-101-0/+12
| | | | | | | | | In the `Visual Studio 15 2017` generator, if the `VS150COMNTOOLS` environment variable points at a specific VS 2017 instance reported by the Visual Studio Installer tool, use that as the preferred instance. Inspired-by: Iyyappa Murugandi <iyyappam@microsoft.com> Fixes: #16846
* Merge topic 'remove-xcode-2'Brad King2017-04-241-0/+2
|\ | | | | | | | | | | | | | | | | 7373b389 Xcode: Drop support for Xcode versions below 3 eaf53849 Xcode: Compute version number earlier Acked-by: Kitware Robot <kwrobot@kitware.com> Reviewed-by: Gregor Jasny <gjasny@googlemail.com> Merge-request: !737
| * Xcode: Drop support for Xcode versions below 3Brad King2017-04-221-0/+2
| |
* | Deprecate Visual Studio 8 2005 generatorBrad King2017-04-211-1/+8
|/ | | | | Update documentation to mark the generator deprecated. Add a warning at the end of generation plus an option to turn off the warning.
* Drop Visual Studio 7 .NET 2003 generatorBrad King2017-04-191-7/+3
| | | | This generator has been deprecated since CMake 3.6. Remove it.
* Help: Document VS generator toolset specification syntaxBrad King2017-03-131-6/+2
|
* Allow CodeBlocks for NMake Makefiles JOMKonstantin Podsvirov2017-01-101-0/+3
|
* Merge branch 'vs15-rename-generator' into vs15-rename-generator-for-masterBrad King2016-11-291-6/+6
|\
| * VS: Rename VS 15 generator to 'Visual Studio 15 2017'Roman Wüger2016-11-291-5/+5
| | | | | | | | | | | | | | | | | | The final name of this VS version was announced: https://blogs.msdn.microsoft.com/visualstudio/2016/11/16/visual-studio-2017-rc/ Add the year to the generator name accordingly. For convenience, map the name without the year to the name with the year.
* | VS: Provide an option to use x64 host toolsBrad King2016-10-144-0/+16
| | | | | | | | | | | | | | | | | | | | Visual Studio provides toolchains that are themselves built for 32-bit or 64-bit host architectures. By default it uses the 32-bit tools, but it can be told to prefer the 64-bit tools on 64-bit hosts. Extend the `CMAKE_GENERATOR_TOOLSET` specification to provide a way to request use of the 64-bit host tools. Closes: #15622
* | Help: Document VS and Xcode toolset selectionBrad King2016-10-136-0/+42
|/ | | | | | Add explicit sections to the individual generator documentation to cover the `cmake -T` option along with the default behavior for each generator.
* Help: Clarify that `cmake -A` option sets VS IDE target architectureBrad King2016-09-305-5/+5
|
* Merge topic 'codelite-organize-by-target'Brad King2016-09-271-1/+5
|\ | | | | | | | | cbe48879 CodeLite: Optionally use targets to create (sub)project files
| * CodeLite: Optionally use targets to create (sub)project filesMinze Zwerver2016-09-261-1/+5
| | | | | | | | | | | | The basic codelite generator creates .project files based on the `project()` stanza. Add a `CMAKE_CODELITE_USE_TARGETS` option to use the targets instead.
* | Help: Document Ninja generator conditional Fortran supportBrad King2016-09-221-0/+10
|/ | | | Closes: #14215
* VS15: Add Visual Studio 15 generatorBrad King2016-09-071-0/+16
| | | | | | | | | | | | | | | | Call the generator "Visual Studio 15" without any year because the preview version of VS 15 does not provide a year in the product name. Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator and update version numbers accordingly. Add the VS15 enumeration value. Note that we do not need to add a MSVC15 variable or v150 toolset because Visual Studio 15 comes with an updated version of the v140 toolset and remains ABI-compatible. Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14. Closes: #16143
* Ninja: Add `$subdir/{test,install,package}` targetsBrad King2016-08-091-3/+14
| | | | | | | | | | | | | With the Makefile generator one can use `cd $subdir; make install` to build and install targets associated with a given subdirectory. This is not possible to do with the Ninja generator since there is only one `build.ninja` file at the top of the build tree. However, we can approximate it by allowing one to run `ninja $subdir/install` at the top of the tree to build the targets in the corresponding subdirectory and install them. This also makes sense for `test`, `package`, and other GLOBAL_TARGET targets. It was already done for `all` by commit v3.6.0-rc1~240^2~2 (Ninja: Add `$subdir/all` targets, 2016-03-11).
* Deprecate Visual Studio 7 .NET 2003 generatorBrad King2016-04-281-1/+7
| | | | | Update documentation to mark the generator deprecated. Add a warning at the end of generation plus an option to turn off the warning.
* Ninja: Add `$subdir/all` targetsCharles Huet2016-03-181-0/+4
| | | | | | | | | | | | | With the Makefile generator one can use `cd $subdir; make all` to build all targets associated with a given subdirectory. This is not possible to do with the Ninja generator since there is only one `build.ninja` file at the top of the build tree. However, we can approximate it by allowing one to run `ninja $subdir/all` at the top of the tree to build the targets in the corresponding subdirectory. Port logic from cmGlobalUnixMakefileGenerator3::WriteDirectoryRule2 to cmGlobalNinjaGenerator in order to produce equivalent directory-level targets.
* Drop Visual Studio 7 generator for VS .NET 2002Brad King2016-03-111-7/+3
| | | | This generator has been deprecated since CMake 3.3. Remove it.
* Drop Visual Studio 6 generatorBrad King2016-03-091-7/+3
| | | | | | This generator has been deprecated since CMake 3.3. Remove it. Update documentation, modules, and tests to drop content specific to this generator.
generated by cgit v0.12 at 2024-11-12 01:37:58 (GMT)