2022-08-17 18:39:49 +02:00
|
|
|
cmake_minimum_required(VERSION 3.20)
|
2020-12-18 21:44:13 +01:00
|
|
|
|
2022-07-27 08:27:38 +02:00
|
|
|
# Options
|
2024-02-24 10:06:21 +01:00
|
|
|
option(IMHEX_PLUGINS_IN_SHARE "Put the plugins in share/imhex/plugins instead of lib[..]/imhex/plugins (Linux only)" OFF)
|
|
|
|
|
option(IMHEX_STRIP_RELEASE "Strip the release builds" ON )
|
|
|
|
|
option(IMHEX_OFFLINE_BUILD "Enable offline build" OFF)
|
|
|
|
|
option(IMHEX_IGNORE_BAD_CLONE "Disable the bad clone prevention checks" OFF)
|
|
|
|
|
option(IMHEX_PATTERNS_PULL_MASTER "Download latest files from master branch of the ImHex-Patterns repo" OFF)
|
|
|
|
|
option(IMHEX_IGNORE_BAD_COMPILER "Allow compiling with an unsupported compiler" OFF)
|
|
|
|
|
option(IMHEX_USE_GTK_FILE_PICKER "Use GTK file picker instead of xdg-desktop-portals (Linux only)" OFF)
|
|
|
|
|
option(IMHEX_DISABLE_STACKTRACE "Disables support for printing stack traces" OFF)
|
|
|
|
|
option(IMHEX_BUNDLE_DOTNET "Bundle .NET runtime" ON )
|
|
|
|
|
option(IMHEX_ENABLE_LTO "Enables Link Time Optimizations if possible" OFF)
|
|
|
|
|
option(IMHEX_USE_DEFAULT_BUILD_SETTINGS "Use default build settings" OFF)
|
|
|
|
|
option(IMHEX_STRICT_WARNINGS "Enable most available warnings and treat them as errors" ON )
|
|
|
|
|
option(IMHEX_STATIC_LINK_PLUGINS "Statically link all plugins into the main executable" OFF)
|
|
|
|
|
option(IMHEX_GENERATE_PACKAGE "Specify if a native package should be built. (Windows and MacOS only)" OFF)
|
|
|
|
|
option(IMHEX_ENABLE_UNITY_BUILD "Enables building ImHex as a unity build." OFF)
|
|
|
|
|
option(IMHEX_GENERATE_PDBS "Enable generating PDB files in non-debug builds (Windows only)" OFF)
|
|
|
|
|
option(IMHEX_REPLACE_DWARF_WITH_PDB "Remove DWARF information from binaries when generating PDBS (Windows only)" OFF)
|
|
|
|
|
option(IMHEX_ENABLE_STD_ASSERTS "Enable debug asserts in the C++ std library. (Breaks Plugin ABI!)" OFF)
|
2024-02-26 20:51:08 +01:00
|
|
|
option(IMHEX_ENABLE_UNIT_TESTS "Enable building unit tests" OFF)
|
2024-03-02 11:28:24 +01:00
|
|
|
option(IMHEX_ENABLE_PRECOMPILED_HEADERS "Enable precompiled headers" OFF)
|
2024-06-03 23:06:28 +02:00
|
|
|
option(IMHEX_COMPRESS_DEBUG_INFO "Compress debug information" ON )
|
2022-07-27 08:27:38 +02:00
|
|
|
|
build: Xcode accomodating CMake setup (#1688)
### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.
### Implementation description
#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:
By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.
The result is different output directories when using Xcode, and no
changes when using any other generator.
#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.
In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```
This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.
#### Problem 3: Vanilla CMake + Xcode = Bad developer UX
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.
Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.
The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.
### Screenshots
N/A
### Additional things
As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.
The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
2024-05-20 12:12:57 +02:00
|
|
|
set(IMHEX_BASE_FOLDER "${CMAKE_CURRENT_SOURCE_DIR}")
|
|
|
|
|
set(CMAKE_MODULE_PATH "${IMHEX_BASE_FOLDER}/cmake/modules")
|
|
|
|
|
|
|
|
|
|
# Optional IDE support
|
|
|
|
|
include("${IMHEX_BASE_FOLDER}/cmake/ide_helpers.cmake")
|
|
|
|
|
|
2022-07-27 08:27:38 +02:00
|
|
|
# Basic compiler and cmake configurations
|
2022-07-15 11:37:10 +02:00
|
|
|
set(CMAKE_CXX_STANDARD 23)
|
2022-10-01 11:02:59 +02:00
|
|
|
set(CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
|
2024-10-22 16:20:08 +02:00
|
|
|
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
|
2022-02-08 09:32:38 +01:00
|
|
|
include("${IMHEX_BASE_FOLDER}/cmake/build_helpers.cmake")
|
2020-12-29 22:50:11 +01:00
|
|
|
|
2022-07-27 08:45:33 +02:00
|
|
|
# Setup project
|
2024-06-05 20:59:48 +02:00
|
|
|
loadVersion(IMHEX_VERSION IMHEX_VERSION_PLAIN)
|
2022-07-27 08:45:33 +02:00
|
|
|
setVariableInParent(IMHEX_VERSION ${IMHEX_VERSION})
|
build: Xcode accomodating CMake setup (#1688)
### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.
### Implementation description
#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:
By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.
The result is different output directories when using Xcode, and no
changes when using any other generator.
#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.
In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```
This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.
#### Problem 3: Vanilla CMake + Xcode = Bad developer UX
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.
Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.
The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.
### Screenshots
N/A
### Additional things
As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.
The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
2024-05-20 12:12:57 +02:00
|
|
|
|
2024-09-15 15:55:21 +02:00
|
|
|
configureCMake()
|
2023-02-01 09:20:46 +01:00
|
|
|
project(imhex
|
2024-02-24 10:06:21 +01:00
|
|
|
LANGUAGES C CXX
|
2024-06-03 23:06:28 +02:00
|
|
|
VERSION ${IMHEX_VERSION_PLAIN}
|
2024-02-24 10:06:21 +01:00
|
|
|
DESCRIPTION "The ImHex Hex Editor"
|
|
|
|
|
HOMEPAGE_URL "https://imhex.werwolv.net"
|
2023-02-01 09:20:46 +01:00
|
|
|
)
|
build: Xcode accomodating CMake setup (#1688)
### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.
### Implementation description
#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:
By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.
The result is different output directories when using Xcode, and no
changes when using any other generator.
#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.
In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```
This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.
#### Problem 3: Vanilla CMake + Xcode = Bad developer UX
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.
Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.
The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.
### Screenshots
N/A
### Additional things
As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.
The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
2024-05-20 12:12:57 +02:00
|
|
|
configureProject()
|
2022-07-27 08:45:33 +02:00
|
|
|
|
2024-03-11 21:08:23 +01:00
|
|
|
# Add ImHex sources
|
|
|
|
|
add_custom_target(imhex_all ALL)
|
|
|
|
|
|
2022-01-15 00:14:12 +01:00
|
|
|
# Make sure project is configured correctly
|
|
|
|
|
setDefaultBuiltTypeIfUnset()
|
|
|
|
|
detectBadClone()
|
2022-08-02 11:59:29 +02:00
|
|
|
verifyCompiler()
|
2022-01-15 00:14:12 +01:00
|
|
|
|
2023-12-23 21:09:41 +01:00
|
|
|
detectBundledPlugins()
|
2020-12-28 20:03:50 +01:00
|
|
|
|
2022-01-15 00:14:12 +01:00
|
|
|
# Add various defines
|
2021-01-27 00:00:20 +01:00
|
|
|
detectOS()
|
2023-05-05 22:03:45 +02:00
|
|
|
addDefines()
|
2024-01-04 17:55:53 +01:00
|
|
|
|
|
|
|
|
# Configure packaging and install targets
|
2022-01-15 00:14:12 +01:00
|
|
|
configurePackingResources()
|
2022-10-14 15:35:45 +02:00
|
|
|
setUninstallTarget()
|
2023-01-04 12:34:38 +01:00
|
|
|
addBundledLibraries()
|
2021-01-27 00:00:20 +01:00
|
|
|
|
2022-01-16 14:20:52 +01:00
|
|
|
add_subdirectory(lib/libimhex)
|
2022-01-15 00:14:12 +01:00
|
|
|
add_subdirectory(main)
|
2024-03-12 19:09:01 +01:00
|
|
|
addPluginDirectories()
|
2021-01-12 16:50:15 +01:00
|
|
|
|
2022-01-15 00:14:12 +01:00
|
|
|
# Add unit tests
|
2024-02-26 20:51:08 +01:00
|
|
|
if (IMHEX_ENABLE_UNIT_TESTS)
|
|
|
|
|
enable_testing()
|
|
|
|
|
add_subdirectory(tests EXCLUDE_FROM_ALL)
|
|
|
|
|
endif ()
|
2021-09-11 14:41:18 +02:00
|
|
|
|
2024-01-04 17:55:53 +01:00
|
|
|
# Configure more resources that will be added to the install package
|
2023-06-20 11:55:56 +02:00
|
|
|
generatePDBs()
|
2024-03-11 21:08:23 +01:00
|
|
|
generateSDKDirectory()
|
2024-03-21 21:56:27 +01:00
|
|
|
|
|
|
|
|
# Handle package generation
|
|
|
|
|
createPackage()
|
build: Xcode accomodating CMake setup (#1688)
### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.
### Implementation description
#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:
By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.
The result is different output directories when using Xcode, and no
changes when using any other generator.
#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.
In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```
This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.
#### Problem 3: Vanilla CMake + Xcode = Bad developer UX
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.
Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.
The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.
### Screenshots
N/A
### Additional things
As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.
The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
2024-05-20 12:12:57 +02:00
|
|
|
|
2024-07-01 08:24:59 +02:00
|
|
|
# Accommodate IDEs with FOLDER support
|
build: Xcode accomodating CMake setup (#1688)
### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.
### Implementation description
#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:
By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.
The result is different output directories when using Xcode, and no
changes when using any other generator.
#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.
In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```
This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.
#### Problem 3: Vanilla CMake + Xcode = Bad developer UX
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.
Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.
The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.
### Screenshots
N/A
### Additional things
As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.
The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
2024-05-20 12:12:57 +02:00
|
|
|
tweakTargetsForIDESupport()
|
