<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
Accomodate -> Accommodate
### Implementation description
<!-- Explain what you did to correct the problem -->
### Screenshots
<!-- If your change is visual, take a screenshot showing it. Ideally,
make before/after sceenshots -->
### Additional things
<!-- Anything else you would like to say -->
This PR compress the debug info in the ELF files built.
This has no impact on the packages (e.g. .deb files) because they themselves have compression, but once installed in the filesystem, they this compression will be beneficial
The compression is opportunistic, happens automatically when possible
For some reason, the web version doesn't work with this (most compiler tests after this seem to fail ?) so it is disabled there
More information: https://github.com/WerWolv/ImHex/issues/1714#issuecomment-2131373826
### 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.
This PR adds a test architecture to be able to test plugins
Main infrastructure done by @WerWolv
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
This PR intends to add support for .NET scripts that can extend ImHex's
functionality in a portable and cross-platform way.
---------
Co-authored-by: Justus Garbe <55301990+Nowilltolife@users.noreply.github.com>
This is aimed at use by linux distros, where package updates come from a
central location, and users shouldn't need to worry about updating ImHex
on their own. This disables parts of the ImHex UI that would not be
useful in that case.
Tested and confirmed that this works in both states of the of the
`-DIMHEX_DISABLE_UPDATE_CHECK` switch.
* Added option to bundle CA
* use bundled CA for AppImage
* Fix bundled CA not working on Linux
* revert change to add null terminated string
* set IMHEX_USE_BUNDLED_CA to ON on Windows
* install deb package in a different folder than AppImage
* added comment for Ubuntu cmake build
* fixed typos
* separate cmake build for deb and appimage
* cmake: use GNUInstallDirs to find install dirs on Linux
* install plugins to lib/imhex/plugins
* fix included files in imhex.spec
* fix the release CI + do not upload x86_64 folder for Fedora
* change rpm names
* added IMHEX_STRIP_RELEASE option to optionally strip releases files (was done all the time before)
* Customize our imhex.spec file (use online building for our Fedora package)
* added IMHEX_PLUGINS_IN_SHARE option for AppImage
* test
