Now it properly fails if libmagic is not installed in the system.
The error message would look like:
```
CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Magic (missing: LIBMAGIC_LIBRARY LIBMAGIC_INCLUDE_DIR)
(Required is at least version "5.39")
Call Stack (most recent call first):
cmake/modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
cmake/modules/FindMagic.cmake:5 (find_package_handle_standard_args)
cmake/build_helpers.cmake:971 (find_package)
CMakeLists.txt:81 (addBundledLibraries)
```
### Problem description
The current `FindMagic.cmake` module doesn't properly report failure
about absent libmagic libs and #includes. This behavior leads to the
compile errors on the build stage (possibly after some time, which will
be simply wasted). This Find module should set the `Magic_FOUND`
variable and handle all required variables( LIBMAGIC_INCLUDE_DIR and
LIBMAGIC_LIBRARY) to present.
But the current module sets the `libmagic_FOUND` variable, so the CMake
assumes that it is found something. This behaviour should also be
handled by `find_package_handle_standard_args()` ("FPHSA"), and it is
actually handled, but as we requested the `Magic` package to be
required, the former function ("FPHSA") didn't stop the configure
process.
### Implementation description
- Clean up the unused ifs, as "FPHSA" already done it better.
- Use the proper name for "FPHSA" so it could set the proper
`Magic_FOUND` and could make sure that the requested package is
`REQUIRED`.
### Screenshots
Before:
```
-- Could NOT find libmagic (missing: LIBMAGIC_LIBRARY LIBMAGIC_INCLUDE_DIR)
```
<img width="1005" height="24" alt="изображение"
src="https://github.com/user-attachments/assets/082e2842-ff94-4418-8f86-86021c7dd23d"
/>
After:
```
CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Magic (missing: LIBMAGIC_LIBRARY LIBMAGIC_INCLUDE_DIR)
(Required is at least version "5.39")
Call Stack (most recent call first):
cmake/modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
cmake/modules/FindMagic.cmake:5 (find_package_handle_standard_args)
cmake/build_helpers.cmake:971 (find_package)
CMakeLists.txt:81 (addBundledLibraries)
```
### Additional things
Closes#2244 .
Partially fixes#2068 .
This assumes the headers are in "include" for all plugins - this is
necessary since the INCLUDES argument of add_imhex_plugin may contain
paths to third party libs, whose headers should not be copied.
To fix this I think it is necessary to add a second argument like
"PRIVATE_INCLUDES", which is included, but not installed.
With this it possible to append the ui plugin for example:
```
INCLUDES
$ENV{IMHEX_SDK_PATH}/lib/plugins/ui/
```
and to link against it:
```
LIBRARIES
/usr/local/lib/imhex/plugins/ui.hexpluglib
```
In a follow-up in the CMake Template for plugins imho there should be
fixed, that:
- you can include plugin includes relative to the SDK Path
- you can link plugins relative to the lib path + without the hexpluglib
or hexplug extension
---------
Co-authored-by: Tim Blume <git@3nd.io>
Co-authored-by: Nik <werwolv98@gmail.com>
### 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>
