Project-wide CMakeLists.txt files to build the toolchain, and then all samples. - #2
Project-wide CMakeLists.txt files to build the toolchain, and then all samples.#2seclorum wants to merge 22 commits into
Conversation
…n), fix ask_name() functions to not be Windows-only, update FloppyBuilder to remove c++-20-style code (only one line!)
…nto macos-tahoe-build-fixups
…on time, with these priorities: DESTINATION= > OSDK= > CMAKE_INSTALL_PREFIX=; e.g. OSDK=~/Desktop/custom-local-osdk-install/ cmake --build <cmake-build-dir> --target build_and_install
…igures and builds every istalled sample using the install prefix; installed CMake helper now automatically OSDK_ROOT from its own sample/cmake location, so standalone installed samples no longer require OSDK_ROOT or OSDK to be set. ; DESTINATION=/private/tmp/osdk-all-samples-final cmake --build /private/tmp/osdk-all-samples-build --target samples
… a means to get the OSDK built, then the samples built.
|
Note: I verified by hand tests that the version of the OSDK built with this PR produces viable .TAP and .DSK files. However, as there is no automated test suite yet, please use the CMake tooling with caution. |
…e builds, or CMake, depending on their preferences. The older Makefiles' still produce the same build products as before - CMake does not replace it - it is rather an additional feature for devs who prefer CMake for their projects.
|
Note - this PR also includes previous updates to the existing Makefile build harness, specifically for Linux and MacOS Tahoe. The previous PR which addressed Linux/MacOS Tahoe fixes has been cancelled, as these fixes were a prerequisite to getting CMake fully operational as a build harness, and that is now completed with this PR. All prior build methods should still function exactly as before, albeit with fixes for Linux/MacOS - this means the prior method of using Makefile and .BAT files is still relevant and still works for all OSDK users, as it always has - however now MacOS and Linux users can build their own native version of the OSDK tooling. This also obviates the need to set up Wine to run the OSDK. Adding CMake capabilities to the project, however, gives better options for building the tools locally - i.e. not using a hand-rolled distribution .zip/.exe - and it also solves a lot of architecture/platform scaffolding issues that were present in the previous build harnesses. Please take time to assess this PR carefully, as it is an important upgrade to the OSDK and will help keep the OSDK coherent and equivalent on a variety of platforms and architectures. Note also that the samples/ have also received their own CMake treatement, obviating the need for Oric devs to wrangle a script-based build system. (CMake is quite friendly to use with other modern IDE’s besides VSCode, also...) |
|
TODO: Document for Oric developers the means by which OSDK can be added to an Oric project and used as a submodule for any new Oric development. |
… destination of the OSDK distributable directory, the distributable will be placed in /distributable/OSDK2.0/ by default.
1 participant
This PR contains a full update of the OSDK build system to use CMake, including a master CMakeLists.txt to build all of the OSDK tools, and a CMakeLists.txt file for each sample, building the resulting .TAP/.DSK files with the locally built tools.
This means that new OSDK devs can build OSDK from source, and all samples.
To test:
Note: further options for building the OSDK and installing it to a local directory are available in the BUILDING.md file.