Some build system tweaks #1879
Some build system tweaks #1879
Conversation
| @@ -387,7 +387,7 @@ function(configureProject) | |||
| # Support Xcode's multi configuration paradigm by placing built artifacts into separate directories | |||
| set(IMHEX_MAIN_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/Configs/$<CONFIG>" PARENT_SCOPE) | |||
| else() | |||
| set(IMHEX_MAIN_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}" PARENT_SCOPE) | |||
| set(IMHEX_MAIN_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin" PARENT_SCOPE) | |||
There was a problem hiding this comment.
This should probably only be done on Linux as Windows and macOS use a different structure
There was a problem hiding this comment.
I thought that Windows was set up to use MinGW (effectively GCC), which would also work with these changes. In terms of file layout (e.g. executable next to shared objects next to pattern files), I anticipated that they should be compatible though I didn't test the windows build yet.
I also didn't touch the XCODE output path, which I assumed was the macOS build method. I don't have a mac to test with, but it looked like it would correctly separate out the differently configured builds.
cmake/build_helpers.cmake
Outdated
| else() | ||
| # If it is an offline build, the imhex_patterns_SOURCE_DIR location is likely a git clone | ||
| # Create the directories as symbolic links, so that any changes get mirrored both ways | ||
| file(CREATE_LINK "${imhex_patterns_SOURCE_DIR}/${FOLDER}" "${IMHEX_MAIN_OUTPUT_DIRECTORY}/${FOLDER}" SYMBOLIC) |
There was a problem hiding this comment.
Is a symbolic link a good idea? Not all file systems support it.
I don't think the two-way mirroring is really necessary so a simple copy should suffice I think
There was a problem hiding this comment.
As I have been making modifications in the PatternLibrary too, I found it useful to edit in-place next to the binary. I mostly was intending to avoid changes there getting lost.
I notice that there is a COPY_ON_ERROR flag for CREATE_LINK that I seem to have missed, which should fall back to a copy if the symbolic link is not supported.
|
Thanks a lot! |
… files if creating the symbolic link fails
|
Tested these changes under windows (using msys2)
|
* Reorganize plugin tests, to fix test registration * Link manually cloned ImHex-Patterns to cmake (fixes code completion and adds unit tests) * Fix IMHEX_STATIC_LINK_PLUGINS to at least build
… to not complain about missing CMakeLists of currently not merged ImHex-Patterns
* null pointer deref, because GImGui wasn't set before ImGui::GetTime was called * use after free when ViewHexEditor tried to write settings in its destructor
…d hex::ImHexApi::System::impl::cleanup
* Readd unintentional removal of USE_SYSTEM_CAPSTONE
…fore adding it as a subdirectory
|
Whole bunch of work to fix macOS |
While setting up a dev environment using WSL2 and docker, to better isolate the tools required from those required by other projects, I made the following tweaks.
The primary aim was to improve IDE integration for the debugging process, by allowing the resulting binaries to be run directly from their build output location. Although cmake is pretty resilient in terms of tracking where it places generated outputs, for use in the later install step, I don't have any of the other environments set up (such as xcode or github workflows) to verify that I didn't break any assumptions they may have.
.devcontainerto the.gitignore- I think this directory may be vscode + remote container extension specific, so ignoring it in the same vein as ignoring e.g..vscode.cacheandcompile_commands.jsonto the.gitignore, as these are generated files / directories used by clangd (via vscode extension)CMAKE_EXPORT_COMPILE_COMMANDS- useful for other tooling (such as clangd), but harmless on its ownRUNTIME_OUTPUT_DIRECTORYthat should have beenLIBRARY_OUTPUT_DIRECTORYIMHEX_MAIN_OUTPUT_DIRECTORYto be${CMAKE_BINARY_DIR}/bin, to separate build outputs from intermediate outputs. Not familiar with xcode, but it appears to already have had some form of separationIMHEX_MAIN_OUTPUT_DIRECTORY- this co-locates the build outputs and allows the imhex binary to be run (and debugged) from that build locationIMHEX_OFFLINE_BUILD) or copy from the download of the patterns (if notIMHEX_OFFLINE_BUILD). This allows the patterns to be available to the build directory instance of imhex, and have any changes between them and the repo be mirrored (if applicable). Again, xcode appears to already have some form of 'copy to build directory' that isn't an install step