mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-19 00:46:45 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/flang/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

606 lines
21 KiB
CMake
Raw Normal View History

Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 18:12:32 +02:00
cmake_minimum_required(VERSION 3.20.0)
[flang] Revise IDE folder structure (#89745) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-05-25 17:24:58 +02:00
set(LLVM_SUBPROJECT_TITLE "Flang")
[flang] Revert "Schauveau cmake" Original-commit: flang-compiler/f18@be33dc182a9bcfa664095886ca62b3b1db4eb797 Reviewed-on: https://github.com/flang-compiler/f18/pull/7
2018-02-14 09:06:47 -08:00
Harmonize cmake_policy() across standalone builds of all projects Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared `cmake/modules/CMakePolicy.cmake`. Include it from all relevant projects that support standalone builds, in order to ensure that the policies are consistently set whether they are built in-tree or stand-alone. Differential Revision: https://reviews.llvm.org/D136572
2022-10-24 06:31:37 +02:00
if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
endif()
include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
NO_POLICY_SCOPE)
[CMake] Remove dead code setting policies to NEW cmake_minimum_required(VERSION) calls cmake_policy(VERSION), which sets all policies up to VERSION to NEW. LLVM started requiring CMake 3.13 last year, so we can remove a bunch of code setting policies prior to 3.13 to NEW as it no longer has any effect. Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D94374
2021-01-10 14:11:35 +02:00
set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
[flang] Enable building f18 as shared libraries Original-commit: flang-compiler/f18@4544d75af1b45e4c554a35327461311cff974884 Reviewed-on: https://github.com/flang-compiler/f18/pull/265 Tree-same-pre-rewrite: false
2019-01-19 14:38:31 -08:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Flang requires C++17.
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
set(CMAKE_CXX_EXTENSIONS OFF)
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] Raise configure-time error when LLVM_ENABLE_EH is set flang cannot be built with exceptions enabled. Doing so results in a link-time error. This addresses issue #59353 [https://github.com/llvm/llvm-project/issues/59353] Differential Revision: https://reviews.llvm.org/D146173
2023-04-26 13:49:58 -06:00
if (LLVM_ENABLE_EH)
# To match with the flang guidelines we currently disable
# building with exception support in core LLVM.
message(FATAL_ERROR "Flang does not currently support building with \
LLVM exceptions enabled. Please disable LLVM_ENABLE_EH when building \
flang.")
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(FLANG_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
[Flang][NFC] Move runtime library files to flang-rt (#110298) Mostly mechanical changes in preparation of extracting the Flang-RT "subproject" in #110217. This PR intends to only move pre-existing files to the new folder structure, with no behavioral change. Common files (headers, testing, cmake) shared by Flang-RT and Flang remain in `flang/`. Some cosmetic changes and files paths were necessary: * Relative paths to the new path for the source files and `add_subdirectory`. * Add the new location's include directory to `include_directories` * The unittest/Evaluate directory has unitests for flang-rt and Flang. A new `CMakeLists.txt` was introduced for the flang-rt tests. * Change the `#include` paths relative to the include directive * clang-format on the `#include` directives * Since the paths are part if the copyright header and include guards, a script was used to canonicalize those * `test/Runtime` and runtime tests in `test/Driver` are moved, but the lit.cfg.py mechanism to execute the will only be added in #110217.
2025-02-16 13:25:31 +01:00
set(FLANG_RT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang-rt")
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] set the paths for the symbol extracting tool (#131375) This patch is to set the paths for tools used in the `export_executable_symbols` function in standalone build and set the necessary macros for compiling the runtime source.
2025-03-21 16:18:16 -04:00
# Python is needed for symbol extracting tool
set(LLVM_MINIMUM_PYTHON_VERSION 3.8)
find_package(Python3 ${LLVM_MINIMUM_PYTHON_VERSION} REQUIRED
COMPONENTS Interpreter)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR AND NOT MSVC_IDE)
message(FATAL_ERROR "In-source builds are not allowed. \
Please create a directory and run cmake from there,\
passing the path to this source directory as the last argument.\
This process created the file `CMakeCache.txt' and the directory\
`CMakeFiles'. Please delete them.")
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
endif()
[flang] Manual backport of sch_llvm branch Original-commit: flang-compiler/f18@17ee2d8e3ac5bfb633cc2792ee7873c543696e72 Reviewed-on: https://github.com/flang-compiler/f18/pull/78 Tree-same-pre-rewrite: false
2018-05-03 14:54:53 +02:00
[flang] Turn off FLANG_ENABLE_WERROR by default Summary: This is a follow up to https://reviews.llvm.org/D78306 Reviewers: DavidTruby, sscalpone, jdoerfert Reviewed By: DavidTruby Subscribers: tskeith, Meinersbur, ChinouneMehdi, richard.barton.arm, mehdi_amini, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D81695
2020-07-14 10:59:26 -05:00
option(FLANG_ENABLE_WERROR "Fail and stop building flang if a warning is triggered." OFF)
[flang] Use LLVM's flags Summary: The only difference is that LLVM_ENABLE_WERROR is set to OFF by default, but we enable this in a standalone flang build This commit fixes some windows issues with the flags Reviewers: DavidTruby, jdoerfert, sscalpone Reviewed By: DavidTruby, sscalpone Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D78306
2020-06-08 15:08:35 +01:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Check for a standalone build and configure as appropriate from
# there.
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
[flang] Use LLVM's flags Summary: The only difference is that LLVM_ENABLE_WERROR is set to OFF by default, but we enable this in a standalone flang build This commit fixes some windows issues with the flags Reviewers: DavidTruby, jdoerfert, sscalpone Reviewed By: DavidTruby, sscalpone Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D78306
2020-06-08 15:08:35 +01:00
message("Building Flang as a standalone project.")
project(Flang)
[flang]Fix individual tests with lit when building out of tree Summary: Fix individual check tests with lit when building out-of-tree `ninja check-flang-<folder>` was not working. The CMakeLists.txt was looking for the lit tests in the source directory instead of the build directory. This commit extends @CarolineConcatto previous patch[D81002] Reviewers: DavidTruby, sscalpone, tskeith, CarolineConcatto, jdoerfert Reviewed By: DavidTruby Subscribers: flang-commits, llvm-commits, CarolineConcatto Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D82120
2020-06-22 10:24:28 +05:30
set(FLANG_STANDALONE_BUILD ON)
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
else()
set(FLANG_STANDALONE_BUILD OFF)
endif()
# Must go below project(..)
include(GNUInstallDirs)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
[FLANG] Fix MSVC + clang-cl build Flang build on windows with MSVC environment and clang-cl compiler requires clang_rt.builtin.${target} library. This patch allows us to locate and include this link library. This is mostly needed for flang runtime and associated unittests as it requires the uint128 division builtin function __udivti3. Reviewed By: DavidTruby Differential Revision: https://reviews.llvm.org/D138023
2022-11-30 16:28:13 +05:00
# MSVC + clang-cl build requires clang_rt.builtin.${target} library
if (MSVC AND CMAKE_CXX_COMPILER_ID MATCHES Clang)
include(HandleCompilerRT)
find_compiler_rt_library(builtins CLANG_RT_BUILTINS_LIBRARY)
get_filename_component(LIBDIR "${CLANG_RT_BUILTINS_LIBRARY}" DIRECTORY)
if (IS_DIRECTORY "${LIBDIR}")
link_libraries(${CLANG_RT_BUILTINS_LIBRARY})
endif()
[flang] Add cmake error if building with clang-cl and MSVC 17.12 (#120114)
2024-12-18 06:15:29 +00:00
if (MSVC_VERSION EQUAL 1942)
message(FATAL_ERROR "Flang cannot be built with clang and the MSVC 17.12 "
"toolchain version. Please upgrade to 17.13 or later, or switch "
"to the 17.10 LTSC release. "
"See https://github.com/microsoft/STL/issues/4959 for more details.")
endif()
[FLANG] Fix MSVC + clang-cl build Flang build on windows with MSVC environment and clang-cl compiler requires clang_rt.builtin.${target} library. This patch allows us to locate and include this link library. This is mostly needed for flang runtime and associated unittests as it requires the uint128 division builtin function __udivti3. Reviewed By: DavidTruby Differential Revision: https://reviews.llvm.org/D138023
2022-11-30 16:28:13 +05:00
endif()
flang: break the build on 32bit systems Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D141132
2023-01-06 17:12:03 +01:00
if(CMAKE_SIZEOF_VOID_P EQUAL 4)
message(FATAL_ERROR "flang isn't supported on 32 bit CPUs")
endif()
[mlir][cmake] Do not export MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR (#125842) MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR point to the source directory, which is not installed. As such, the installed MLIRConfig.cmake also should not reference it. The comment indicates that these are needed for mlir_tablegen(), but I don't see any related uses. The motivation for this is the use in flang, where we end up inheriting a meaningless MLIR_MAIN_SRC_DIR from a previous MLIR build, whose source directory doesn't exist anymore, and that cannot be overridden with the correct path, because it's not a cached variable. Instead do what all the other projects do for LLVM_MAIN_SRC_DIR and initialize MLIR_MAIN_SRC_DIR to CMAKE_CURRENT_SOURCE_DIR/../mlir. For MLIR_INCLUDE_DIR there already is an exported MLIR_INCLUDE_DIRS, which can be used instead.
2025-02-11 14:32:30 +01:00
set(MLIR_MAIN_SRC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../mlir" CACHE PATH "Path to MLIR source tree")
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
if (FLANG_STANDALONE_BUILD)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(FLANG_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
[flang] Fix for 541f5c4a6db35870091dd15dfa09dde751229a17 (D140524) breaking out-of-tree flang build.
2023-06-03 15:13:09 +02:00
set(CMAKE_INCLUDE_CURRENT_DIR ON)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (NOT MSVC_IDE)
set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
CACHE BOOL "Enable assertions")
# Assertions follow llvm's configuration.
mark_as_advanced(LLVM_ENABLE_ASSERTIONS)
endif()
[flang] set the paths for the symbol extracting tool (#131375) This patch is to set the paths for tools used in the `export_executable_symbols` function in standalone build and set the necessary macros for compiling the runtime source.
2025-03-21 16:18:16 -04:00
# Build with _XOPEN_SOURCE on AIX to avoid errors caused by _ALL_SOURCE.
# We need to enable the large-file API as well.
if (UNIX AND CMAKE_SYSTEM_NAME MATCHES "AIX")
add_compile_definitions(_XOPEN_SOURCE=700)
add_compile_definitions(_LARGE_FILE_API)
endif()
[cmake] Use absolute paths for modules search For out of tree builds, the user generally needs to specify LLVM_DIR and MLIR_DIR on the command line so that the correct LLVM and MLIR installations are picked up. If the provided paths are absolute, everything works fine, however for buildbots it is customary to work with relative paths, and that makes it difficult for CMake to find the right modules to include. This patch changes CMakeLists.txt to convert LLVM_DIR and MLIR_DIR to absolute paths before adding them to CMAKE_MODULE_PATH. The inputs are assumed to be relative to the source directory (llvm-project/flang). Differential Revision: https://reviews.llvm.org/D87083
2020-09-03 13:39:29 +02:00
# If the user specifies a relative path to LLVM_DIR, the calls to include
# LLVM modules fail. Append the absolute path to LLVM_DIR instead.
[flang] Support discovering LLVM/Clang/MLIR without explicit *_DIR (#122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way #120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
2025-01-13 18:18:12 +01:00
if (LLVM_DIR)
get_filename_component(LLVM_DIR_ABSOLUTE ${LLVM_DIR}
REALPATH BASE_DIR ${CMAKE_CURRENT_BINARY_DIR})
list(APPEND CMAKE_MODULE_PATH ${LLVM_DIR_ABSOLUTE})
endif()
Revert "[flang] Fix finding system install of LLVM/Clang/MLIR in standalone builds (#120914)" This reverts commit 8e12037d38e2a9a1cfc6402be2b33283e3220bcc. It broke the flang-aarch64-out-of-tree buildbot.
2025-01-10 19:04:57 +01:00
# We need a pre-built/installed version of LLVM.
find_package(LLVM REQUIRED HINTS "${LLVM_DIR_ABSOLUTE}")
[flang] Support discovering LLVM/Clang/MLIR without explicit *_DIR (#122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way #120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
2025-01-13 18:18:12 +01:00
if (NOT LLVM_DIR_ABSOLUTE)
# If the user did not specify a LLVM_DIR (and therefore LLVM_DIR_ABSOLUTE
# was not set), append the discovered path to CMAKE_MODULE_PATH.
list(APPEND CMAKE_MODULE_PATH ${LLVM_DIR})
endif()
[flang] Manual backport of sch_llvm branch Original-commit: flang-compiler/f18@17ee2d8e3ac5bfb633cc2792ee7873c543696e72 Reviewed-on: https://github.com/flang-compiler/f18/pull/78 Tree-same-pre-rewrite: false
2018-05-03 14:54:53 +02:00
[flang][driver] Delete `f18` (i.e. the old Flang driver) This patch removes `f18`, a.k.a. the old driver. It is being replaced with the new driver, `flang-new`, which has reached feature parity with `f18` a while ago. This was discussed in [1] and also in [2]. With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is also deleted. This means that we are making the dependency on Clang permanent (i.e. it cannot be disabled with a CMake flag). LIT set-up is updated accordingly. All references to `f18` or `f18.cpp` are either updated or removed. The `F18_FC` variable from the `flang` bash script is replaced with `FLANG_FC`. The former is still supported for backwards compatibility. [1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html [2] https://reviews.llvm.org/D103177 Differential Revision: https://reviews.llvm.org/D105811
2021-07-12 08:44:38 +00:00
# Users might specify a path to CLANG_DIR that's:
# * a full path, or
# * a path relative to the path of this script.
# Append the absolute path to CLANG_DIR so that find_package works in both
# cases.
[flang] Support discovering LLVM/Clang/MLIR without explicit *_DIR (#122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way #120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
2025-01-13 18:18:12 +01:00
if (CLANG_DIR)
get_filename_component(
CLANG_DIR_ABSOLUTE
${CLANG_DIR}
REALPATH
BASE_DIR ${CMAKE_CURRENT_BINARY_DIR})
list(APPEND CMAKE_MODULE_PATH ${CLANG_DIR_ABSOLUTE})
# TODO: Remove when libclangDriver is lifted out of Clang
find_package(Clang REQUIRED PATHS "${CLANG_DIR_ABSOLUTE}" NO_DEFAULT_PATH)
else()
find_package(Clang REQUIRED)
list(APPEND CMAKE_MODULE_PATH ${Clang_DIR})
Revert "[flang] Fix finding system install of LLVM/Clang/MLIR in standalone builds (#120914)" This reverts commit 8e12037d38e2a9a1cfc6402be2b33283e3220bcc. It broke the flang-aarch64-out-of-tree buildbot.
2025-01-10 19:04:57 +01:00
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# If LLVM links to zlib we need the imported targets so we can too.
if(LLVM_ENABLE_ZLIB)
find_package(ZLIB REQUIRED)
endif()
[flang] Use LLVM's flags Summary: The only difference is that LLVM_ENABLE_WERROR is set to OFF by default, but we enable this in a standalone flang build This commit fixes some windows issues with the flags Reviewers: DavidTruby, jdoerfert, sscalpone Reviewed By: DavidTruby, sscalpone Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D78306
2020-06-08 15:08:35 +01:00
option(LLVM_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
[flang] Disable -Wmaybe-uninitialized for GCC According to llvm/cmake/config-ix.cmake, gcc's potentially uninitialized use analysis has lots of false positives. We are encountering one in flang/lib/Lower/CharacterExpr.cpp. That warning is disabled for gcc in in-tree builds; this does the same thing for out-of-tree builds. Differential Revision: https://reviews.llvm.org/D85694
2020-08-11 07:20:13 -07:00
if(CMAKE_COMPILER_IS_GNUCXX)
set(USE_NO_MAYBE_UNINITIALIZED 1)
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
[flang] set the paths for the symbol extracting tool (#131375) This patch is to set the paths for tools used in the `export_executable_symbols` function in standalone build and set the necessary macros for compiling the runtime source.
2025-03-21 16:18:16 -04:00
# The path is needed to locate extract_symbols.py
if (NOT DEFINED LLVM_MAIN_SRC_DIR)
set(LLVM_MAIN_SRC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../llvm")
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
include(AddLLVM)
include(HandleLLVMOptions)
include(VersionFromVCS)
[flang] Refine output file generation This patch cleans-up the file generation code in Flang's frontend driver. It improves the layering between `CompilerInstance::CreateDefaultOutputFile`, `CompilerInstance::CreateOutputFile` and their various clients. * Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it private. This method is an implementation detail. * Instead of passing an `std::error_code` out parameter into `CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter and idiomatic LLVM. * Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`) issue an error when file creation fails. The error code from `CreateOutputFileImpl` is used to generate a meaningful diagnostic message. * Remove error reporting from `PrintPreprocessedAction::ExecuteAction`. This is only for cases when output file generation fails. This is handled in `CreateDefaultOutputFile` instead (see the previous point). * Inline `AddOutputFile` into its only caller, `CreateDefaultOutputFile`. * Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>` for non-seekable output streams. This simplifies the logic in the driver and was introduced for this very reason in [1] * Moke sure that the diagnostics from the prescanner when running `-E` (`PrintPreprocessedAction::ExecuteAction`) are printed before the actual output is generated. * Update comments, add test. NOTE: This patch relands [2]. As suggested by Michael Kruse in the post-commit/post-revert review, I've added the following: ``` config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@" ``` in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in output-paths.f90 gets the correct value on Windows as well as on Linux. [1] https://reviews.llvm.org/D93260 [2] fd21d1e198e381a2b9e7af1701044462b2d386cd Reviewed By: ashermancinelli Differential Revision: https://reviews.llvm.org/D108390
2021-08-20 10:25:11 +00:00
include(GetErrcMessages)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
[flang][driver] Delete `f18` (i.e. the old Flang driver) This patch removes `f18`, a.k.a. the old driver. It is being replaced with the new driver, `flang-new`, which has reached feature parity with `f18` a while ago. This was discussed in [1] and also in [2]. With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is also deleted. This means that we are making the dependency on Clang permanent (i.e. it cannot be disabled with a CMake flag). LIT set-up is updated accordingly. All references to `f18` or `f18.cpp` are either updated or removed. The `F18_FC` variable from the `flang` bash script is replaced with `FLANG_FC`. The former is still supported for backwards compatibility. [1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html [2] https://reviews.llvm.org/D103177 Differential Revision: https://reviews.llvm.org/D105811
2021-07-12 08:44:38 +00:00
include(AddClang)
[flang] Fix CMake bug in the definition of flang-new Recent patch that improved Flang's compatibility with respect to how LLVM dynamic libraries should be linked (and specified in CMake recipes), introduced a bug in the definition of `flang-new`: * https://reviews.llvm.org/D87893 More specifically, `add_flang_tool` does not support the `LINK_COMPONENTS` CMake argument. Instead, one should set `LLVM_LINK_COMPONENTS` before calling `add_flang_tool`. This patch reverts the change for `flang-new` from https://reviews.llvm.org/D87893, and instead: * sets `LLVM_LINK_COMPONENTS` * calls `clang_target_link_libraries` to add Clang dependencies Differential Revision: https://reviews.llvm.org/D89403
2020-10-14 17:40:29 +01:00
[flang] Remove `LINK_WITH_FIR` cmake switch Most components required for this are already there. Build and Testing clean. ninja check-flang Reviewed By: clementval, tskeith Differential Revision: https://reviews.llvm.org/D96411
2021-02-10 18:23:10 +05:30
include(TableGen)
# If the user specifies a relative path to MLIR_DIR, the calls to include
# MLIR modules fail. Append the absolute path to MLIR_DIR instead.
[flang] Support discovering LLVM/Clang/MLIR without explicit *_DIR (#122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way #120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
2025-01-13 18:18:12 +01:00
if (MLIR_DIR)
get_filename_component(MLIR_DIR_ABSOLUTE ${MLIR_DIR}
REALPATH BASE_DIR ${CMAKE_CURRENT_BINARY_DIR})
list(APPEND CMAKE_MODULE_PATH ${MLIR_DIR_ABSOLUTE})
endif()
Revert "[flang] Fix finding system install of LLVM/Clang/MLIR in standalone builds (#120914)" This reverts commit 8e12037d38e2a9a1cfc6402be2b33283e3220bcc. It broke the flang-aarch64-out-of-tree buildbot.
2025-01-10 19:04:57 +01:00
find_package(MLIR REQUIRED CONFIG HINTS ${MLIR_DIR_ABSOLUTE})
[flang] Support discovering LLVM/Clang/MLIR without explicit *_DIR (#122639) Support discovering LLVM, Clang and MLIR via the standard CMake logic in addition to explicitly specified `LLVM_DIR`, etc. To prevent breaking anyone's workflow the way #120914 did, this change explicitly introduces two possible code paths based on variables provided: 1. If `LLVM_DIR`, etc. are defined, the current logic is used as-is. 2. If they are not defined, `find_package()` is called normally to discover the packages using the standard CMake logic, and the discovered paths are added --------- Co-authored-by: Slava Zakharin <szakharin@nvidia.com>
2025-01-13 18:18:12 +01:00
if (NOT MLIR_DIR_ABSOLUTE)
list(APPEND CMAKE_MODULE_PATH ${MLIR_DIR})
endif()
Reland "[flang][build] Fixed paths discrovery for the out-of-tree build. (#87822)" This reverts commit 215eee60497489ae0cc7cc78c0d8b8270e057a70.
2024-04-19 08:51:26 -07:00
# Use SYSTEM for the same reasons as for LLVM includes
include_directories(SYSTEM ${MLIR_INCLUDE_DIRS})
[flang] Remove `LINK_WITH_FIR` cmake switch Most components required for this are already there. Build and Testing clean. ninja check-flang Reviewed By: clementval, tskeith Differential Revision: https://reviews.llvm.org/D96411
2021-02-10 18:23:10 +05:30
include(AddMLIR)
find_program(MLIR_TABLEGEN_EXE "mlir-tblgen" ${LLVM_TOOLS_BINARY_DIR}
NO_DEFAULT_PATH)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
option(LLVM_INSTALL_TOOLCHAIN_ONLY
"Only include toolchain files in the 'install' target." OFF)
[cmake] Correct option to LLVM_FORCE_USE_OLD_TOOLCHAIN This option was renamed a long time ago in commit 388cefa78d.
2023-05-17 10:28:58 +02:00
option(LLVM_FORCE_USE_OLD_TOOLCHAIN
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
"Set to ON to force using an old, unsupported host toolchain." OFF)
[flang] Regression tests configuration for f18 repository (flang-compiler/f18#861) The configuration for the tests are in lit.* files. The lit tests rely on the presence of llvm-lit,FileCheck, not and count. When building LLVM add: -DLLVM_INSTALL_UTILS=On at the cmake command. LLVM_LIT is found by setting LLVM_EXTERNAL_LIT in f18 CMakeLists.txt. This patch: * Uses LLVM_EXTERNAL_LIT * Adds regression tests configurations * Adds a proof of concept regression test The regression test needs to have the Utils build in LLVM. This is done by adding: -DLLVM_INSTALL_UTILS=On to the LLVM build cmake. Signed-off-by: Caroline Concatto <caroline.concatto@arm.com> Original-commit: flang-compiler/f18@a58c6067a1ab5cd02dfb5b6fb9919a20b960d984 Reviewed-on: https://github.com/flang-compiler/f18/pull/861
2020-01-14 16:20:49 +00:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Add LLVM include files as if they were SYSTEM because there are complex unused
# parameter issues that may or may not appear depending on the environments and
# compilers (ifdefs are involved). This allows warnings from LLVM headers to be
# ignored while keeping -Wunused-parameter a fatal error inside f18 code base.
# This may have to be fine-tuned if flang headers are consider part of this
# LLVM_INCLUDE_DIRS when merging in the monorepo (Warning from flang headers
# should not be suppressed).
include_directories(SYSTEM ${LLVM_INCLUDE_DIRS})
add_definitions(${LLVM_DEFINITIONS})
[flang] Manual backport of sch_llvm branch Original-commit: flang-compiler/f18@17ee2d8e3ac5bfb633cc2792ee7873c543696e72 Reviewed-on: https://github.com/flang-compiler/f18/pull/78 Tree-same-pre-rewrite: false
2018-05-03 14:54:53 +02:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# LLVM's cmake configuration files currently sneak in a c++11 flag.
# We look for it here and remove it from Flang's compile flags to
# avoid some mixed compilation flangs (e.g. -std=c++11 ... -std=c++17).
if (DEFINED LLVM_CXX_STD)
message("LLVM configuration set a C++ standard: ${LLVM_CXX_STD}")
if (NOT LLVM_CXX_STD EQUAL "c++17")
message("Flang: Overriding LLVM's 'cxx_std' setting...")
message(" removing '-std=${LLVM_CXX_STD}'")
message(" CMAKE_CXX_FLAGS='${CMAKE_CXX_FLAGS}'")
string(REPLACE " -std=${LLVM_CXX_STD}" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
message(" [NEW] CMAKE_CXX_FLAGS='${CMAKE_CXX_FLAGS}'")
endif()
endif()
[flang] Manual backport of sch_llvm branch Original-commit: flang-compiler/f18@17ee2d8e3ac5bfb633cc2792ee7873c543696e72 Reviewed-on: https://github.com/flang-compiler/f18/pull/78 Tree-same-pre-rewrite: false
2018-05-03 14:54:53 +02:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
link_directories("${LLVM_LIBRARY_DIR}")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 22:44:46 -04:00
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 22:44:46 -04:00
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(LLVM_EXTERNAL_LIT "${LLVM_TOOLS_BINARY_DIR}/llvm-lit" CACHE STRING "Command used to spawn lit")
[Flang] Support overriding `LLVM_LIT_ARGS` in standalone builds (#127340) Declare `LLVM_LIT_ARGS` as a cache variable in standalone builds to permit overriding it. This mirrors the logic used in Clang.
2025-02-15 20:50:14 +01:00
set(LIT_ARGS_DEFAULT "-sv")
if (MSVC OR XCODE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
endif()
set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
option(FLANG_INCLUDE_TESTS
"Generate build targets for the Flang unit tests."
ON)
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
[flang] Refine output file generation This patch cleans-up the file generation code in Flang's frontend driver. It improves the layering between `CompilerInstance::CreateDefaultOutputFile`, `CompilerInstance::CreateOutputFile` and their various clients. * Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it private. This method is an implementation detail. * Instead of passing an `std::error_code` out parameter into `CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter and idiomatic LLVM. * Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`) issue an error when file creation fails. The error code from `CreateOutputFileImpl` is used to generate a meaningful diagnostic message. * Remove error reporting from `PrintPreprocessedAction::ExecuteAction`. This is only for cases when output file generation fails. This is handled in `CreateDefaultOutputFile` instead (see the previous point). * Inline `AddOutputFile` into its only caller, `CreateDefaultOutputFile`. * Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>` for non-seekable output streams. This simplifies the logic in the driver and was introduced for this very reason in [1] * Moke sure that the diagnostics from the prescanner when running `-E` (`PrintPreprocessedAction::ExecuteAction`) are printed before the actual output is generated. * Update comments, add test. NOTE: This patch relands [2]. As suggested by Michael Kruse in the post-commit/post-revert review, I've added the following: ``` config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@" ``` in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in output-paths.f90 gets the correct value on Windows as well as on Linux. [1] https://reviews.llvm.org/D93260 [2] fd21d1e198e381a2b9e7af1701044462b2d386cd Reviewed By: ashermancinelli Differential Revision: https://reviews.llvm.org/D108390
2021-08-20 10:25:11 +00:00
get_errc_messages(LLVM_LIT_ERRC_MESSAGES)
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
#Handle unittests when out-of-tree
set(FLANG_GTEST_AVAIL 0)
if (FLANG_INCLUDE_TESTS)
[flang] Fix unittests in standalone build for third-party move Update external unittest rules for flang standalone builds to account for the unittest components (gtest, gmock) being moved to `third-party` directory, in a11cd0d94ed3cabf0998a0289aead05da94c86eb. Differential Revision: https://reviews.llvm.org/D138562
2022-11-23 13:19:47 +01:00
set(UNITTEST_DIR ${LLVM_THIRD_PARTY_DIR}/unittest)
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
if(EXISTS ${UNITTEST_DIR}/googletest/include/gtest/gtest.h)
Reapply "[cmake] Prefix gtest and gtest_main with "llvm_"." This reverts commit 7cdda6b8ce49ae3c90c068cff4dc355bba5d77f2. Differential Revision: https://reviews.llvm.org/D121020
2022-03-04 12:08:04 -08:00
if (NOT TARGET llvm_gtest)
[flang] Harmonize standalone gtest support with other projects Use the CMake rules of unittest libraries via `add_subdirectory()` when using standalone builds, similarly to how e.g. Clang does that. Besides making things more consistent, I hope this also unblocks D137035 and effectively we'll be able to simplify things further and have LLVM semi-automatically include gtest support for us in the future. Differential Revision: https://reviews.llvm.org/D138573
2022-11-23 16:07:03 +01:00
add_subdirectory(${UNITTEST_DIR} third-party/unittest)
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
endif()
set(FLANG_GTEST_AVAIL 1)
else()
message(WARNING
"Unit-tests will be skipped as LLVM install does not include google-test related headers and libraries.")
set(FLANG_GTEST_AVAIL 0)
endif()
endif()
if (FLANG_GTEST_AVAIL)
add_custom_target(check-all DEPENDS check-flang FlangUnitTests)
else()
Revert "[Flang] [FlangRT] Introduce FlangRT project as solution to Flang's runtime LLVM integration" This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70. This is failing on all but 1 of Linaro's flang builders. CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message): Target llvm_gtest not found.
2023-10-02 09:01:11 +00:00
add_custom_target(check-all DEPENDS check-flang )
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
endif()
[flang][docs] Doxygen support in flang. Summary: Added support for doxygen-style documentation generation from source code. Added -DLLVM_ENABLE_DOXYGEN=ON -DFLANG_INCLUDE_DOCS=ON flags to cmake. Added the target doxygen-flang for building doxygen Updated README.txt Reviewers: DavidTruby, richard.barton.arm, sscalpone, mehdi_amini, jdoerfert Reviewed By: DavidTruby, richard.barton.arm, sscalpone Previous review: https://github.com/flang-compiler/f18/pull/1065 Differential Revision: https://reviews.llvm.org/D78136
2020-04-27 14:52:36 +05:30
if (LLVM_BUILD_DOCS)
add_custom_target(doxygen ALL)
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
else()
option(FLANG_INCLUDE_TESTS
"Generate build targets for the Flang unit tests."
${LLVM_INCLUDE_TESTS})
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
set(FLANG_GTEST_AVAIL 1)
[Flang] Fix multi-config generator builds Based on https://reviews.llvm.org/D84022 with additional changes to maintain out-of-tree builds. Original commit message: Currently the binaries are output directly into the bin subdirectory of the build directory. This doesn't work correctly with multi-config generators which should output the binaries into <CONFIG_NAME>/bin instead. The original patch was implemented by David Truby and the additional changes added here were also proposed by David Truby. Differential Revision: https://reviews.llvm.org/D85078/ Co-authored-by: David Truby <david.truby@arm.com>
2020-08-01 20:53:27 +01:00
if(FLANG_STANDALONE_BUILD)
set(FLANG_BINARY_DIR ${CMAKE_BINARY_DIR}/tools/flang)
else()
set(FLANG_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
endif()
[mlir][cmake] Do not export MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR (#125842) MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR point to the source directory, which is not installed. As such, the installed MLIRConfig.cmake also should not reference it. The comment indicates that these are needed for mlir_tablegen(), but I don't see any related uses. The motivation for this is the use in flang, where we end up inheriting a meaningless MLIR_MAIN_SRC_DIR from a previous MLIR build, whose source directory doesn't exist anymore, and that cannot be overridden with the correct path, because it's not a cached variable. Instead do what all the other projects do for LLVM_MAIN_SRC_DIR and initialize MLIR_MAIN_SRC_DIR to CMAKE_CURRENT_SOURCE_DIR/../mlir. For MLIR_INCLUDE_DIR there already is an exported MLIR_INCLUDE_DIRS, which can be used instead.
2025-02-11 14:32:30 +01:00
set(MLIR_INCLUDE_DIRS ${MLIR_MAIN_SRC_DIR}/include ) # --includedir
[flang] Remove `LINK_WITH_FIR` cmake switch Most components required for this are already there. Build and Testing clean. ninja check-flang Reviewed By: clementval, tskeith Differential Revision: https://reviews.llvm.org/D96411
2021-02-10 18:23:10 +05:30
set(MLIR_TABLEGEN_OUTPUT_DIR ${CMAKE_BINARY_DIR}/tools/mlir/include)
[mlir][cmake] Do not export MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR (#125842) MLIR_MAIN_SRC_DIR and MLIR_INCLUDE_DIR point to the source directory, which is not installed. As such, the installed MLIRConfig.cmake also should not reference it. The comment indicates that these are needed for mlir_tablegen(), but I don't see any related uses. The motivation for this is the use in flang, where we end up inheriting a meaningless MLIR_MAIN_SRC_DIR from a previous MLIR build, whose source directory doesn't exist anymore, and that cannot be overridden with the correct path, because it's not a cached variable. Instead do what all the other projects do for LLVM_MAIN_SRC_DIR and initialize MLIR_MAIN_SRC_DIR to CMAKE_CURRENT_SOURCE_DIR/../mlir. For MLIR_INCLUDE_DIR there already is an exported MLIR_INCLUDE_DIRS, which can be used instead.
2025-02-11 14:32:30 +01:00
include_directories(SYSTEM ${MLIR_INCLUDE_DIRS})
[flang] Remove `LINK_WITH_FIR` cmake switch Most components required for this are already there. Build and Testing clean. ninja check-flang Reviewed By: clementval, tskeith Differential Revision: https://reviews.llvm.org/D96411
2021-02-10 18:23:10 +05:30
include_directories(SYSTEM ${MLIR_TABLEGEN_OUTPUT_DIR})
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
endif()
[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as `CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when downstream projects try to install there too this breaks because our builds always install to fresh directories for isolation's sake. Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the other specially crafted `LLVM_CONFIG_*` variables substituted in `llvm/cmake/modules/LLVMConfig.cmake.in`. @beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a dangling reference in `AddLLVM`, but I am suspicious of how this variable doesn't follow the pattern. Those other ones are carefully made to be build-time vs install-time variables depending on which `LLVMConfig.cmake` is being generated, are carefully made relative as appropriate, etc. etc. For my NixOS use-case they are also fine because they are never used as downstream install variables, only for reading not writing. To avoid the problems I face, and restore symmetry, I deleted the exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s. `AddLLVM` now instead expects each project to define its own, and they do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports `LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in the usual way, matching the other remaining exported variables. For the `AddLLVM` changes, I tried to copy the existing pattern of internal vs non-internal or for LLVM vs for downstream function/macro names, but it would good to confirm I did that correctly. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117977
2022-06-11 06:11:59 +00:00
[Flang] LLVM_ENABLE_RUNTIMES=flang-rt (#110217) Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME mechanism. It will only become active when `LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the `FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is passed, nothing changes with the current build process. Motivation: * Consistency with LLVM's other runtime libraries (compiler-rt, libc, libcxx, openmp offload, ...) * Allows compiling the runtime for multiple targets at once using the LLVM_RUNTIME_TARGETS configuration options * Installs the runtime into the compiler's per-target resource directory so it can be automatically found even when cross-compiling Also see RFC discussion at https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
2025-02-16 15:39:52 +01:00
set(FLANG_INCLUDE_RUNTIME_default ON)
if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
set(FLANG_INCLUDE_RUNTIME_default OFF)
endif ()
option(FLANG_INCLUDE_RUNTIME "Build the runtime in-tree (deprecated; to be replaced with LLVM_ENABLE_RUNTIMES=flang-rt)" ${FLANG_INCLUDE_RUNTIME_default})
if (FLANG_INCLUDE_RUNTIME)
if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
message(WARNING "Building Flang-RT using LLVM_ENABLE_RUNTIMES. FLANG_INCLUDE_RUNTIME=${FLANG_INCLUDE_RUNTIME} ignored.")
set(FLANG_INCLUDE_RUNTIME OFF)
else ()
message(STATUS "Building Flang-RT in-tree")
endif ()
else ()
if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
message(STATUS "Building Flang-RT using LLVM_ENABLE_RUNTIMES")
else ()
message(STATUS "Not building Flang-RT. For a usable Fortran toolchain, either add LLVM_ENABLE_RUNTIMES=flang-rt, or compile a standalone Flang-RT.")
endif ()
endif ()
[Flang] Optionally do not compile the runtime in-tree (#122336) Introduce the CMake switch FLANG_INCLUDE_RUNTIME. When set to off, do not add build instructions for the runtime. This is required for Flang-RT (#110217) and the current runtime CMake code to co-exist. When using `LLVM_ENABLE_RUNTIME=flang-rt`, the in-tree build instructions are in conflict and must be disabled.
2025-02-08 01:06:27 +01:00
[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as `CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when downstream projects try to install there too this breaks because our builds always install to fresh directories for isolation's sake. Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the other specially crafted `LLVM_CONFIG_*` variables substituted in `llvm/cmake/modules/LLVMConfig.cmake.in`. @beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a dangling reference in `AddLLVM`, but I am suspicious of how this variable doesn't follow the pattern. Those other ones are carefully made to be build-time vs install-time variables depending on which `LLVMConfig.cmake` is being generated, are carefully made relative as appropriate, etc. etc. For my NixOS use-case they are also fine because they are never used as downstream install variables, only for reading not writing. To avoid the problems I face, and restore symmetry, I deleted the exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s. `AddLLVM` now instead expects each project to define its own, and they do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports `LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in the usual way, matching the other remaining exported variables. For the `AddLLVM` changes, I tried to copy the existing pattern of internal vs non-internal or for LLVM vs for downstream function/macro names, but it would good to confirm I did that correctly. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117977
2022-06-11 06:11:59 +00:00
set(FLANG_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
"Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')")
mark_as_advanced(FLANG_TOOLS_INSTALL_DIR)
[flang] Build intrinsic .mod files in include/flang The build was putting .mod files for intrinsic modules in tools/flang/include/flang but the install puts them in include/flang, as does the out-of-tree build. This confused things for the driver. This change makes the build consistent with the install and simplifies the flang script accordingly. Also, clean up the cmake commands for building the .mod files. Differential Revision: https://reviews.llvm.org/D98522
2021-03-15 08:02:58 -07:00
set(FLANG_INTRINSIC_MODULES_DIR ${CMAKE_BINARY_DIR}/include/flang)
Enable export of FIR includes into the install tree https://reviews.llvm.org/D102040
2021-05-10 16:41:29 -07:00
set(FLANG_INCLUDE_DIR ${FLANG_BINARY_DIR}/include)
[flang] Regression tests configuration for f18 repository (flang-compiler/f18#861) The configuration for the tests are in lit.* files. The lit tests rely on the presence of llvm-lit,FileCheck, not and count. When building LLVM add: -DLLVM_INSTALL_UTILS=On at the cmake command. LLVM_LIT is found by setting LLVM_EXTERNAL_LIT in f18 CMakeLists.txt. This patch: * Uses LLVM_EXTERNAL_LIT * Adds regression tests configurations * Adds a proof of concept regression test The regression test needs to have the Utils build in LLVM. This is done by adding: -DLLVM_INSTALL_UTILS=On to the LLVM build cmake. Signed-off-by: Caroline Concatto <caroline.concatto@arm.com> Original-commit: flang-compiler/f18@a58c6067a1ab5cd02dfb5b6fb9919a20b960d984 Reviewed-on: https://github.com/flang-compiler/f18/pull/861
2020-01-14 16:20:49 +00:00
[flang][driver] Delete `f18` (i.e. the old Flang driver) This patch removes `f18`, a.k.a. the old driver. It is being replaced with the new driver, `flang-new`, which has reached feature parity with `f18` a while ago. This was discussed in [1] and also in [2]. With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is also deleted. This means that we are making the dependency on Clang permanent (i.e. it cannot be disabled with a CMake flag). LIT set-up is updated accordingly. All references to `f18` or `f18.cpp` are either updated or removed. The `F18_FC` variable from the `flang` bash script is replaced with `FLANG_FC`. The former is still supported for backwards compatibility. [1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html [2] https://reviews.llvm.org/D103177 Differential Revision: https://reviews.llvm.org/D105811
2021-07-12 08:44:38 +00:00
# TODO: Remove when libclangDriver is lifted out of Clang
if(FLANG_STANDALONE_BUILD)
set(CLANG_INCLUDE_DIR ${CLANG_INCLUDE_DIRS} )
# No need to specify TableGen output dir as that's embedded in CLANG_DIR
else()
set(CLANG_INCLUDE_DIR ${LLVM_MAIN_SRC_DIR}/../clang/include )
# Specify TableGen output dir for things like DiagnosticCommonKinds.inc,
# DiagnosticDriverKinds.inc (required for reporting diagnostics)
set(CLANG_TABLEGEN_OUTPUT_DIR ${CMAKE_BINARY_DIR}/tools/clang/include)
include_directories(SYSTEM ${CLANG_TABLEGEN_OUTPUT_DIR})
[flang][driver] Add the new flang compiler and frontend drivers Summary: This is the first patch implementing the new Flang driver as outlined in [1], [2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver (`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the current Flang throwaway driver, `flang`, can be replaced with `flang-new`. Currently only 2 options are supported: `-help` and `--version`. `flang-new` is implemented in terms of libclangDriver, defaulting the driver mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the driver runs in Flang mode regardless of the name of the binary inferred from argv[0]. The design of the new Flang compiler and frontend drivers is inspired by it counterparts in Clang [3]. Currently, the new Flang compiler and frontend drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend. To identify Flang options, this patch adds FlangOption/FC1Option enums. Driver::printHelp is updated so that `flang-new` prints only Flang options. The new Flang driver is disabled by default. To enable it, set `-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to `LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”). [1] “RFC: new Flang driver - next steps” http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html [2] “RFC: Adding a fortran mode to the clang driver for flang” http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html [3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang” http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html [4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: richard.barton.arm, sameeranjoshi Differential Revision: https://reviews.llvm.org/D86089
2020-09-11 10:17:31 +01:00
endif()
[flang][driver] Delete `f18` (i.e. the old Flang driver) This patch removes `f18`, a.k.a. the old driver. It is being replaced with the new driver, `flang-new`, which has reached feature parity with `f18` a while ago. This was discussed in [1] and also in [2]. With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is also deleted. This means that we are making the dependency on Clang permanent (i.e. it cannot be disabled with a CMake flag). LIT set-up is updated accordingly. All references to `f18` or `f18.cpp` are either updated or removed. The `F18_FC` variable from the `flang` bash script is replaced with `FLANG_FC`. The former is still supported for backwards compatibility. [1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html [2] https://reviews.llvm.org/D103177 Differential Revision: https://reviews.llvm.org/D105811
2021-07-12 08:44:38 +00:00
include_directories(SYSTEM ${CLANG_INCLUDE_DIR})
[flang][driver] Add the new flang compiler and frontend drivers Summary: This is the first patch implementing the new Flang driver as outlined in [1], [2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver (`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the current Flang throwaway driver, `flang`, can be replaced with `flang-new`. Currently only 2 options are supported: `-help` and `--version`. `flang-new` is implemented in terms of libclangDriver, defaulting the driver mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the driver runs in Flang mode regardless of the name of the binary inferred from argv[0]. The design of the new Flang compiler and frontend drivers is inspired by it counterparts in Clang [3]. Currently, the new Flang compiler and frontend drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend. To identify Flang options, this patch adds FlangOption/FC1Option enums. Driver::printHelp is updated so that `flang-new` prints only Flang options. The new Flang driver is disabled by default. To enable it, set `-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to `LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”). [1] “RFC: new Flang driver - next steps” http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html [2] “RFC: Adding a fortran mode to the clang driver for flang” http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html [3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang” http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html [4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com> Reviewed By: richard.barton.arm, sameeranjoshi Differential Revision: https://reviews.llvm.org/D86089
2020-09-11 10:17:31 +01:00
[flang] Remove `LINK_WITH_FIR` cmake switch Most components required for this are already there. Build and Testing clean. ninja check-flang Reviewed By: clementval, tskeith Differential Revision: https://reviews.llvm.org/D96411
2021-02-10 18:23:10 +05:30
# tco tool and FIR lib output directories
if(FLANG_STANDALONE_BUILD)
set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/bin)
set(LLVM_LIBRARY_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/lib)
[flang] Add cmake option to link with FIR and LLVM The cmake option -DLINK_WITH_FIR=ON causes the f18 driver to be linked against FIR and LLVM. When it is set to OFF (the default), the call into FIR is #ifdef'd out. The source in lib/FIR is always built; this option only affects linking. Original-commit: flang-compiler/f18@69569edd4c6abbb7a66c0d8f3595858693a06996 Reviewed-on: https://github.com/flang-compiler/f18/pull/329
2019-03-13 12:41:15 -07:00
endif()
[flang] Remove `LINK_WITH_FIR` cmake switch Most components required for this are already there. Build and Testing clean. ninja check-flang Reviewed By: clementval, tskeith Differential Revision: https://reviews.llvm.org/D96411
2021-02-10 18:23:10 +05:30
# Always build tco tool
set(LLVM_BUILD_TOOLS ON)
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
include_directories(BEFORE
${FLANG_BINARY_DIR}/include
${FLANG_SOURCE_DIR}/include)
[flang] Fix standalone builds Flang's CMake modules directory was being added to the CMake module path twice, and AddFlang was being included after the first addition. Remove the unnecessary first addition and move the AddFlang include down to the second one. This way, it occurs after LLVM's CMake modules have been included for a standalone build, so it can make use of those modules.
2021-05-12 12:59:23 -07:00
# Add Flang-centric modules to cmake path.
[flang] Use `GNUInstallDirs` to support custom installation dirs. Extracted from D99484. My new plan is to start from the outside and work inward. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115569
2021-04-04 13:02:18 -04:00
list(INSERT CMAKE_MODULE_PATH 0
"${FLANG_SOURCE_DIR}/cmake/modules"
Set the path to the shared cmake modules based on the llvm directory It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools. Reviewed By: Ericson2314 Differential Revision: https://reviews.llvm.org/D116472
2022-01-01 17:51:16 +00:00
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
[flang] Use `GNUInstallDirs` to support custom installation dirs. Extracted from D99484. My new plan is to start from the outside and work inward. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115569
2021-04-04 13:02:18 -04:00
)
[flang] Fix standalone builds Flang's CMake modules directory was being added to the CMake module path twice, and AddFlang was being included after the first addition. Remove the unnecessary first addition and move the AddFlang include down to the second one. This way, it occurs after LLVM's CMake modules have been included for a standalone build, so it can make use of those modules.
2021-05-12 12:59:23 -07:00
include(AddFlang)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (NOT DEFAULT_SYSROOT)
set(DEFAULT_SYSROOT "" CACHE PATH
"The <path> to use for the system root for all compiler invocations (--sysroot=<path>).")
endif()
if (NOT ENABLE_LINKER_BUILD_ID)
set(ENABLE_LINKER_BUILD_ID OFF CACHE BOOL "pass --build-id to ld")
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(FLANG_DEFAULT_LINKER "" CACHE STRING
"Default linker to use (linker name or absolute path, empty for platform default)")
set(FLANG_DEFAULT_RTLIB "" CACHE STRING
[Flang] Rename libFortranRuntime.a to libflang_rt.runtime.a (#122341) Following the conclusion of the [RFC](https://discourse.llvm.org/t/rfc-names-for-flang-rt-libraries/84321), rename Flang's runtime libraries as follows: * libFortranRuntime.(a|so) to libflang_rt.runtime.(a|so) * libFortranFloat128Math.a to libflang_rt.quadmath.a * libCufRuntime_cuda_${CUDAToolkit_VERSION_MAJOR}.(a|so) to libflang_rt.cuda_${CUDAToolkit_VERSION_MAJOR}.(a|so) This follows the same naming scheme as Compiler-RT libraries (`libclang_rt.${component}.(a|so)`). It provides some consistency between Flang's runtime libraries for current and potential future library components.
2025-02-08 18:02:54 +01:00
"Default Fortran runtime library to use (\"libflang_rt.runtime\"), leave empty for platform default.")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (NOT(FLANG_DEFAULT_RTLIB STREQUAL ""))
message(WARNING "Resetting Flang's default runtime library to use platform default.")
set(FLANG_DEFAULT_RTLIB "" CACHE STRING
"Default runtime library to use (empty for platform default)" FORCE)
endif()
Revert "[flang] Put ISO_Fortran_binding.h where it can be easily used (#69121)" This reverts commit e6e90840708099425b7b69dd053634ff25d4907f. This is to fix https://github.com/llvm/llvm-project/issues/69697.
2023-10-20 09:00:51 -07:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
[flang] Put ISO_Fortran_binding.h where it can be easily used (#70129) The update stems from the discussion in https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442 This is my third attempt at this. My second attempt was in pull request #69121. This is my second attempt at this. My first attempt was in pull request #68756. This pull request has three changes from the second one: - I put the test into the Driver directory rather than Examples so that it would get run without require the define LLVM_BUILD_EXAMPLES. - When installing ISO_Fortran_binding.h, I changed the location where it was installed from. - I changed the test so that it would work when flang was built with shared libraries. Here's the information from my previous attempts: I decided to put ISO_Fortran_binding.h in a place where it would be accessible with the include: "#include<ISO_Fortran_binding.h>" rather than "#include<fortran/ISO_Fortran_binding.h>" because this is what gfortran implements. Note that the file is also installed into ".../include/flang", so if a user wanted to access the file from a compiler other than clang, it would be available. I added a test in ".../flang/test/Driver". To make the test work, I also needed to put ISO_Fortran_binding.h into the build area. Although the flang project depends on clang, clang may not always be available in a flang build. For example, when building just the "check-flang" target, the "clang" executable may not be available at the time the new test gets run. To account for this, I made the test's script check for the existence of the "clang" executable. If "clang" is not available, it simply prints "PASS". If it is available, it fully builds and executes the test. On success, this will also print "PASS"
2023-10-30 06:44:09 -07:00
if (NOT PACKAGE_VERSION)
set(PACKAGE_VERSION ${LLVM_VERSION_MAJOR})
endif()
Revert "[flang] Put ISO_Fortran_binding.h where it can be easily used (#69121)" This reverts commit e6e90840708099425b7b69dd053634ff25d4907f. This is to fix https://github.com/llvm/llvm-project/issues/69697.
2023-10-20 09:00:51 -07:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (NOT DEFINED FLANG_VERSION_MAJOR)
set(FLANG_VERSION_MAJOR ${LLVM_VERSION_MAJOR})
endif()
if (NOT DEFINED FLANG_VERSION_MINOR)
set(FLANG_VERSION_MINOR ${LLVM_VERSION_MINOR})
endif()
if (NOT DEFINED FLANG_VERSION_PATCHLEVEL)
set(FLANG_VERSION_PATCHLEVEL ${LLVM_VERSION_PATCH})
endif()
# Unlike PACKAGE_VERSION, FLANG_VERSION does not include LLVM_VERSION_SUFFIX.
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
set(FLANG_VERSION "${FLANG_VERSION_MAJOR}.${FLANG_VERSION_MINOR}.${FLANG_VERSION_PATCHLEVEL}")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
message(STATUS "Flang version: ${FLANG_VERSION}")
# Flang executable version information
set(FLANG_EXECUTABLE_VERSION
"${FLANG_VERSION_MAJOR}" CACHE STRING
"Major version number to appended to the flang executable name.")
set(LIBFLANG_LIBRARY_VERSION
"${FLANG_VERSION_MAJOR}" CACHE STRING
"Major version number to appended to the libflang library.")
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
mark_as_advanced(FLANG_EXECUTABLE_VERSION LIBFLANG_LIBRARY_VERSION)
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(FLANG_VENDOR ${PACKAGE_VENDOR} CACHE STRING
"Vendor-specific Flang version information.")
set(FLANG_VENDOR_UTI "org.llvm.flang" CACHE STRING
"Vendor-specific uti.")
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (FLANG_VENDOR)
add_definitions(-DFLANG_VENDOR="${FLANG_VENDOR} ")
endif()
[flang] Address review comments Original-commit: flang-compiler/f18@d96917c70130b12462d28189ded5e6243e8c854e Reviewed-on: https://github.com/flang-compiler/f18/pull/101 Tree-same-pre-rewrite: false
2018-06-14 13:43:02 -07:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(FLANG_REPOSITORY_STRING "" CACHE STRING
"Vendor-specific text for showing the repository the source is taken from.")
if (FLANG_REPOSITORY_STRING)
add_definitions(-DFLANG_REPOSITORY_STRING="${FLANG_REPOSITORY_STRING}")
endif()
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Configure Flang's Version.inc file.
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/include/flang/Version.inc.in
${CMAKE_CURRENT_BINARY_DIR}/include/flang/Version.inc)
# Configure Flang's version info header file.
[flang] Add simple recursive CMake directory structure Original-commit: flang-compiler/f18@a021b2ca768c2b8c03d626739d0754ba99e463d2 Reviewed-on: https://github.com/flang-compiler/f18/pull/13 Tree-same-pre-rewrite: false
2018-02-19 14:28:12 +01:00
configure_file(
${FLANG_SOURCE_DIR}/include/flang/Config/config.h.cmake
${FLANG_BINARY_DIR}/include/flang/Config/config.h)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
[flang] Use LLVM's flags Summary: The only difference is that LLVM_ENABLE_WERROR is set to OFF by default, but we enable this in a standalone flang build This commit fixes some windows issues with the flags Reviewers: DavidTruby, jdoerfert, sscalpone Reviewed By: DavidTruby, sscalpone Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D78306
2020-06-08 15:08:35 +01:00
if (FLANG_ENABLE_WERROR)
# The following is taken from llvm/cmake/modules/HandleLLVMOptions.cmake
# Keep this up-to-date with that file
if( MSVC )
append("/WX" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
if ( LLVM_COMPILER_IS_GCC_COMPATIBLE )
append("-Werror" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append("-Wno-error" CMAKE_REQUIRED_FLAGS)
endif( LLVM_COMPILER_IS_GCC_COMPATIBLE )
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Builtin check_cxx_compiler_flag doesn't seem to work correctly
macro(check_compiler_flag flag resultVar)
unset(${resultVar} CACHE)
check_cxx_compiler_flag("${flag}" ${resultVar})
endmacro()
check_compiler_flag("-Werror -Wno-deprecated-copy" CXX_SUPPORTS_NO_DEPRECATED_COPY_FLAG)
if (CXX_SUPPORTS_NO_DEPRECATED_COPY_FLAG)
[flang] Use LLVM's flags Summary: The only difference is that LLVM_ENABLE_WERROR is set to OFF by default, but we enable this in a standalone flang build This commit fixes some windows issues with the flags Reviewers: DavidTruby, jdoerfert, sscalpone Reviewed By: DavidTruby, sscalpone Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D78306
2020-06-08 15:08:35 +01:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-copy")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
endif()
check_compiler_flag("-Wstring-conversion" CXX_SUPPORTS_NO_STRING_CONVERSION_FLAG)
if (CXX_SUPPORTS_NO_STRING_CONVERSION_FLAG)
[flang] Use LLVM's flags Summary: The only difference is that LLVM_ENABLE_WERROR is set to OFF by default, but we enable this in a standalone flang build This commit fixes some windows issues with the flags Reviewers: DavidTruby, jdoerfert, sscalpone Reviewed By: DavidTruby, sscalpone Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D78306
2020-06-08 15:08:35 +01:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-string-conversion")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
endif()
Disable -Wctad-maybe-unsupported in flang since it already uses the feature a lot
2022-08-16 17:42:45 +00:00
check_compiler_flag("-Wno-ctad-maybe-unsupported" CXX_SUPPORTS_NO_CTAD_MAYBE_UNSUPPORTED_FLAG)
if (CXX_SUPPORTS_NO_CTAD_MAYBE_UNSUPPORTED_FLAG)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-ctad-maybe-unsupported")
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Add appropriate flags for GCC
if (LLVM_COMPILER_IS_GCC_COMPATIBLE)
if (NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-strict-aliasing -fno-semantic-interposition")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-command-line-argument -Wstring-conversion \
-Wcovered-switch-default")
endif() # Clang.
check_cxx_compiler_flag("-Werror -Wnested-anon-types" CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG)
if (CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-nested-anon-types")
endif()
[flang] Fix release build flags. Summary: This patch removes the custom CMAKE_RELEASE_CXX_FLAGS variable. This variable being set was having the effect of removing other important Release flags, notably `-DNDEBUG`. This patch may need to be accompanied by fixes for the macOS issues that the removed comment mentions; I don't have a mac to test this on though so hopefully a reviewer can help with that. Reviewers: Andrzej, tskeith, sscalpone Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80794
2020-05-29 14:03:21 +01:00
# Add to build type flags.
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DDEBUGF18")
[flang] Fix release build flags. Summary: This patch removes the custom CMAKE_RELEASE_CXX_FLAGS variable. This variable being set was having the effect of removing other important Release flags, notably `-DNDEBUG`. This patch may need to be accompanied by fixes for the macOS issues that the removed comment mentions; I don't have a mac to test this on though so hopefully a reviewer can help with that. Reviewers: Andrzej, tskeith, sscalpone Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80794
2020-05-29 14:03:21 +01:00
set(CMAKE_CXX_FLAGS_MINSIZEREL "${CMAKE_CXX_FLAGS_MINSIZEREL} -DCHECK=\"(void)\"")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Building shared libraries is bad for performance with GCC by default
# due to the need to preserve the right to override external entry points
if (BUILD_SHARED_LIBS AND NOT (CMAKE_CXX_COMPILER_ID MATCHES "Clang"))
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -fno-semantic-interposition")
endif()
endif()
[flang] Fix Darwin build after 4762c6557d15 (#84478) Select POSIX 2008 standard to avoid including Darwin extensions. Otherwise, Darwin's math.h header defines HUGE, which conflicts with Flang's HUGE function. This started happening after 4762c6557d15 (#82443), that added the "utility" include, which seems to include "math.h".
2024-03-11 08:25:41 -03:00
# Clang on Darwin enables non-POSIX extensions by default, which allows the
# macro HUGE to leak out of <math.h> even when it is never directly included,
# conflicting with Flang's HUGE symbols.
# Set _POSIX_C_SOURCE to avoid including these extensions.
if (APPLE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_POSIX_C_SOURCE=200809")
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
list(REMOVE_DUPLICATES CMAKE_CXX_FLAGS)
# Determine HOST_LINK_VERSION on Darwin.
set(HOST_LINK_VERSION)
if (APPLE)
set(LD_V_OUTPUT)
execute_process(
COMMAND sh -c "${CMAKE_LINKER} -v 2>&1 | head -1"
RESULT_VARIABLE HAD_ERROR
OUTPUT_VARIABLE LD_V_OUTPUT)
if (NOT HAD_ERROR)
if ("${LD_V_OUTPUT}" MATCHES ".*ld64-([0-9.]+).*")
string(REGEX REPLACE ".*ld64-([0-9.]+).*" "\\1" HOST_LINK_VERSION ${LD_V_OUTPUT})
elseif ("${LD_V_OUTPUT}" MATCHES "[^0-9]*([0-9.]+).*")
string(REGEX REPLACE "[^0-9]*([0-9.]+).*" "\\1" HOST_LINK_VERSION ${LD_V_OUTPUT})
endif()
else()
message(FATAL_ERROR "${CMAKE_LINKER} failed with status ${HAD_ERROR}")
endif()
endif()
[flang] Add FLANG_PARALLEL_COMPILE_JOBS option (#127364) This is a re-apply of 083c683969b2436afdc45becadc955841f5f4d31 with a fix for the flang runtime build. This works the same way as LLVM_PARALLEL_COMPILE_JOBS except that it is specific to the flang source rather than for the whole project. Configuring with -DFLANG_PARALLEL_COMPILE_JOBS=1 would mean that there would only ever be one flang source being compiled at a time. Some of the flang sources require large amounts of memory to compile, so this option can be used to avoid OOM erros when compiling those files while still allowing the rest of the project to compile using the maximum number of jobs. Update flang/CMakeLists.txt --------- Co-authored-by: Nikita Popov <github@npopov.com> Co-authored-by: Michael Kruse <github@meinersbur.de>
2025-02-20 11:29:54 -08:00
# Set up job pools for flang. Some of the flang sources take a lot of memory to
# compile, so allow users to limit the number of parallel flang jobs. This is
# useful for building flang alongside several other projects since you can use
# the maximum number of build jobs for the other projects while limiting the
# number of flang compile jobs.
set(FLANG_PARALLEL_COMPILE_JOBS CACHE STRING
"The maximum number of concurrent compilation jobs for Flang (Ninja only)")
if (FLANG_PARALLEL_COMPILE_JOBS)
set_property(GLOBAL APPEND PROPERTY JOB_POOLS flang_compile_job_pool=${FLANG_PARALLEL_COMPILE_JOBS})
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
include(AddFlang)
[Flang] LLVM_ENABLE_RUNTIMES=flang-rt (#110217) Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME mechanism. It will only become active when `LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the `FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is passed, nothing changes with the current build process. Motivation: * Consistency with LLVM's other runtime libraries (compiler-rt, libc, libcxx, openmp offload, ...) * Allows compiling the runtime for multiple targets at once using the LLVM_RUNTIME_TARGETS configuration options * Installs the runtime into the compiler's per-target resource directory so it can be automatically found even when cross-compiling Also see RFC discussion at https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
2025-02-16 15:39:52 +01:00
include(FlangCommon)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
Alias Analysis infra in Flang Differential revision: https://reviews.llvm.org/D136889
2022-11-02 15:39:58 -07:00
if (FLANG_INCLUDE_TESTS)
add_compile_definitions(FLANG_INCLUDE_TESTS=1)
endif()
[flang] Revert "PoC for Flang Driver Plugins" This patch has not been reviewed and was commited by accident. This reverts commit 788a5d4afe6407e647454a9832a7b4a27fba06bf.
2021-07-01 08:27:31 +00:00
[flang][cuda] Allow to set the stack limit size (#124859) This patch adds a call to the CUFInit function just after `ProgramStart` when CUDA Fortran is enabled to initialize the CUDA context. This allows us to set up some context information like the stack limit that can be defined by an environment variable `ACC_OFFLOAD_STACKSIZE=<value>`.
2025-01-28 20:57:33 -08:00
option(FLANG_CUF_RUNTIME
"Compile CUDA Fortran runtime sources" OFF)
if (FLANG_CUF_RUNTIME)
find_package(CUDAToolkit REQUIRED)
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
add_subdirectory(include)
add_subdirectory(lib)
add_subdirectory(cmake/modules)
option(FLANG_BUILD_TOOLS
"Build the Flang tools. If OFF, just generate build targets." ON)
if (FLANG_BUILD_TOOLS)
add_subdirectory(tools)
endif()
[flang][cuda] Add CUF allocator (#101216) Add allocators for CUDA fortran allocation on the device. 3 allocators are added for pinned, device and managed/unified memory allocation. `CUFRegisterAllocator()` is called to register the allocators in the allocator registry added in #100690. Since this require CUDA, a cmake option `FLANG_CUF_RUNTIME` is added to conditionally build these.
2024-08-02 10:02:34 -07:00
[Flang] Optionally do not compile the runtime in-tree (#122336) Introduce the CMake switch FLANG_INCLUDE_RUNTIME. When set to off, do not add build instructions for the runtime. This is required for Flang-RT (#110217) and the current runtime CMake code to co-exist. When using `LLVM_ENABLE_RUNTIME=flang-rt`, the in-tree build instructions are in conflict and must be disabled.
2025-02-08 01:06:27 +01:00
if (FLANG_INCLUDE_RUNTIME)
add_subdirectory(runtime)
endif ()
[flang][driver] Add support for Frontend Plugins Introducing a plugin API and a simple HelloWorld Plugin example. This patch adds the `-load` and `-plugin` flags to frontend driver and the code around using custom frontend actions from within a plugin shared library object. It also adds to the Driver-help test to check the help option with the updated driver flags. Additionally, the patch creates a plugin-example test to check the HelloWorld plugin example runs correctly. As part of this, a new CMake flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built and for the test to run. This Plugin API has only been tested on Linux. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D106137
2021-08-12 11:42:08 +01:00
[flang] Handle Flang examples consistently with LLVM. Without this change the problem is that flangOmpReport and flangPrintFunctionNames libraries are not built under 'all', but they are imported targets via LLVMExports.cmake so that any out-of-tree build that configures upon LLVM+Flang package will get this CMake error: ``` The imported target "flangPrintFunctionNames" references the file ".../lib/flangPrintFunctionNames.so" but this file does not exist. ``` flang-aarch64-out-of-tree buildbot (https://lab.llvm.org/buildbot/#/builders/175) does not catch this issue, because it does not enable Flang on the first stage. This change gets rid of FLANG_BUILD_EXAMPLES in favor of LLVM_BUILD_EXAMPLES and uses available LLVM CMake macros to add example executables/libraries. Differential Revision: https://reviews.llvm.org/D145992
2023-03-13 14:50:13 -07:00
if (LLVM_INCLUDE_EXAMPLES)
add_subdirectory(examples)
[flang] Disable Plugins in out-of-tree builds https://reviews.llvm.org/D106137 added support for plugins in Flang. The CMake configuration for plugins requires some LLVM variables that are not available in out-of-tree builds (e.g. `LLVM_SHLIB_OUTPUT_INTDIR`). This has caused the out-of-tree BuildBot worker to start failing: * https://lab.llvm.org/buildbot/#/builders/175 This patch effectively disables plugins in out-of-tree builds and fixes the configuration error. In order to support plugins in out-of-tree builds, we would have to find a way to access the missing CMake variables from LLVM. This could be implemented at a later time. Differential Revision: https://reviews.llvm.org/D107973
2021-08-12 16:11:54 +00:00
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (FLANG_INCLUDE_TESTS)
add_subdirectory(test)
[flang] unit test support for out-of-tree and in-tree using google tests framework Review comments addressed.
2020-06-02 22:45:44 +05:30
if (FLANG_GTEST_AVAIL)
add_subdirectory(unittests)
endif ()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
endif()
[flang][docs] Doxygen support in flang. Summary: Added support for doxygen-style documentation generation from source code. Added -DLLVM_ENABLE_DOXYGEN=ON -DFLANG_INCLUDE_DOCS=ON flags to cmake. Added the target doxygen-flang for building doxygen Updated README.txt Reviewers: DavidTruby, richard.barton.arm, sscalpone, mehdi_amini, jdoerfert Reviewed By: DavidTruby, richard.barton.arm, sscalpone Previous review: https://github.com/flang-compiler/f18/pull/1065 Differential Revision: https://reviews.llvm.org/D78136
2020-04-27 14:52:36 +05:30
option(FLANG_INCLUDE_DOCS "Generate build targets for the Flang docs."
${LLVM_INCLUDE_DOCS})
if (FLANG_INCLUDE_DOCS)
add_subdirectory(docs)
endif()
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
# Custom target to install Flang libraries.
add_custom_target(flang-libraries)
[flang] Revise IDE folder structure (#89745) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-05-25 17:24:58 +02:00
set_target_properties(flang-libraries PROPERTIES FOLDER "Flang/Meta")
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
if (NOT LLVM_ENABLE_IDE)
add_llvm_install_targets(install-flang-libraries
DEPENDS flang-libraries
COMPONENT flang-libraries)
endif()
get_property(FLANG_LIBS GLOBAL PROPERTY FLANG_LIBS)
if (FLANG_LIBS)
list(REMOVE_DUPLICATES FLANG_LIBS)
foreach(lib ${FLANG_LIBS})
add_dependencies(flang-libraries ${lib})
if (NOT LLVM_ENABLE_IDE)
add_dependencies(install-flang-libraries install-${lib})
endif()
endforeach()
endif()
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
[flang] Add install target to install flang headers (#78151) This makes it more convenient to install flang without using the general `ninja install` to install everything. To install flang-new and associated things one needs `ninja install-flang-new install-flang-libraries install-flang-headers`.
2024-01-16 17:04:52 +00:00
add_llvm_install_targets(install-flang-headers
COMPONENT flang-headers)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
install(DIRECTORY include/flang
[flang] Use `GNUInstallDirs` to support custom installation dirs. Extracted from D99484. My new plan is to start from the outside and work inward. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115569
2021-04-04 13:02:18 -04:00
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
COMPONENT flang-headers
FILES_MATCHING
PATTERN "*.def"
PATTERN "*.h"
PATTERN "*.inc"
PATTERN "*.td"
PATTERN "config.h" EXCLUDE
PATTERN ".git" EXCLUDE
PATTERN "CMakeFiles" EXCLUDE)
Reapply "[cmake] Prefix gtest and gtest_main with "llvm_"." This reverts commit 7cdda6b8ce49ae3c90c068cff4dc355bba5d77f2. Differential Revision: https://reviews.llvm.org/D121020
2022-03-04 12:08:04 -08:00
Enable export of FIR includes into the install tree https://reviews.llvm.org/D102040
2021-05-10 16:41:29 -07:00
install(DIRECTORY ${FLANG_INCLUDE_DIR}/flang
[flang] Use `GNUInstallDirs` to support custom installation dirs. Extracted from D99484. My new plan is to start from the outside and work inward. Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D115569
2021-04-04 13:02:18 -04:00
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
Enable export of FIR includes into the install tree https://reviews.llvm.org/D102040
2021-05-10 16:41:29 -07:00
COMPONENT flang-headers
FILES_MATCHING
PATTERN "*.inc"
)
[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-25 16:22:14 -07:00
endif()
[flang] Put ISO_Fortran_binding.h where it can be easily used (#70129) The update stems from the discussion in https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442 This is my third attempt at this. My second attempt was in pull request #69121. This is my second attempt at this. My first attempt was in pull request #68756. This pull request has three changes from the second one: - I put the test into the Driver directory rather than Examples so that it would get run without require the define LLVM_BUILD_EXAMPLES. - When installing ISO_Fortran_binding.h, I changed the location where it was installed from. - I changed the test so that it would work when flang was built with shared libraries. Here's the information from my previous attempts: I decided to put ISO_Fortran_binding.h in a place where it would be accessible with the include: "#include<ISO_Fortran_binding.h>" rather than "#include<fortran/ISO_Fortran_binding.h>" because this is what gfortran implements. Note that the file is also installed into ".../include/flang", so if a user wanted to access the file from a compiler other than clang, it would be available. I added a test in ".../flang/test/Driver". To make the test work, I also needed to put ISO_Fortran_binding.h into the build area. Although the flang project depends on clang, clang may not always be available in a flang build. For example, when building just the "check-flang" target, the "clang" executable may not be available at the time the new test gets run. To account for this, I made the test's script check for the existence of the "clang" executable. If "clang" is not available, it simply prints "PASS". If it is available, it fully builds and executes the test. On success, this will also print "PASS"
2023-10-30 06:44:09 -07:00
# Put ISO_Fortran_binding.h into the include files of the build area now
# so that we can run tests before installing
include(GetClangResourceDir)
get_clang_resource_dir(HEADER_BINARY_DIR PREFIX ${LLVM_LIBRARY_OUTPUT_INTDIR}/.. SUBDIR include)
configure_file(
${FLANG_SOURCE_DIR}/include/flang/ISO_Fortran_binding.h
[Flang] LLVM_ENABLE_RUNTIMES=flang-rt (#110217) Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME mechanism. It will only become active when `LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the `FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is passed, nothing changes with the current build process. Motivation: * Consistency with LLVM's other runtime libraries (compiler-rt, libc, libcxx, openmp offload, ...) * Allows compiling the runtime for multiple targets at once using the LLVM_RUNTIME_TARGETS configuration options * Installs the runtime into the compiler's per-target resource directory so it can be automatically found even when cross-compiling Also see RFC discussion at https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
2025-02-16 15:39:52 +01:00
${HEADER_BINARY_DIR}/ISO_Fortran_binding.h COPYONLY)
# llvm-test-suite explicitly searches for this header file
# (`ISO_FORTRAN_C_HEADER`), cannot hide it in Clang's resource dir.
configure_file(
${FLANG_SOURCE_DIR}/include/flang/ISO_Fortran_binding.h
${LLVM_RUNTIME_OUTPUT_INTDIR}/../include/flang/ISO_Fortran_binding.h COPYONLY)
[flang] Put ISO_Fortran_binding.h where it can be easily used (#70129) The update stems from the discussion in https://discourse.llvm.org/t/adding-flang-specific-header-files-to-clang/72442 This is my third attempt at this. My second attempt was in pull request #69121. This is my second attempt at this. My first attempt was in pull request #68756. This pull request has three changes from the second one: - I put the test into the Driver directory rather than Examples so that it would get run without require the define LLVM_BUILD_EXAMPLES. - When installing ISO_Fortran_binding.h, I changed the location where it was installed from. - I changed the test so that it would work when flang was built with shared libraries. Here's the information from my previous attempts: I decided to put ISO_Fortran_binding.h in a place where it would be accessible with the include: "#include<ISO_Fortran_binding.h>" rather than "#include<fortran/ISO_Fortran_binding.h>" because this is what gfortran implements. Note that the file is also installed into ".../include/flang", so if a user wanted to access the file from a compiler other than clang, it would be available. I added a test in ".../flang/test/Driver". To make the test work, I also needed to put ISO_Fortran_binding.h into the build area. Although the flang project depends on clang, clang may not always be available in a flang build. For example, when building just the "check-flang" target, the "clang" executable may not be available at the time the new test gets run. To account for this, I made the test's script check for the existence of the "clang" executable. If "clang" is not available, it simply prints "PASS". If it is available, it fully builds and executes the test. On success, this will also print "PASS"
2023-10-30 06:44:09 -07:00
# And also install it into the install area
get_clang_resource_dir(HEADER_INSTALL_DIR SUBDIR include)
install(
FILES include/flang/ISO_Fortran_binding.h
DESTINATION ${HEADER_INSTALL_DIR} )
[flang][runtime] Build ISO_FORTRAN_ENV to export kind arrays as linkable symbols (#95388) Moves definitions of the kind arrays into a Fortran MODULE to not only emit the MOD file, but also compile that MODULE file into an object file. This file is then linked into libFortranRuntime.so. Eventually this workaround PR shoud be redone and a proper runtime build should be setup that will then also compile Fortran MODULE files. Fixes #89403 --------- Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> Co-authored-by: Michael Kruse <github@meinersbur.de>
2024-07-19 19:37:24 +02:00
Reference in New Issue Copy Permalink