So there's been a draft for the computer build (#5) for a really long time. The few times I've messed around I have been able to get it to build (or just grabbed the files to include in whatever I was working on).
It may be a better idea to leave the Makefile in place as a standalone build for ARM, and have CMake be the primary build system generator for all other platforms. (Eventually we could have the cmake file generate the ARM build as well). But this seems like a good compromise, and it only requires adding one file.
I'm working on a few example programs for PCs that use DaisySP (primarily a JUCE plugin, and a VCV Rack plugin) that will need to be able to build the library.
I've already tested creating a project with JUCE and DaisySP using cmake that was able to be up and running in Windows really quickly (though I still need to test on other OSes).
I'm open to others' thoughts on this, but this seems like a good approach for handling builds away from the Daisy Hardware (or ARM in general).
So there's been a draft for the computer build (#5) for a really long time. The few times I've messed around I have been able to get it to build (or just grabbed the files to include in whatever I was working on).
It may be a better idea to leave the
Makefilein place as a standalone build for ARM, and have CMake be the primary build system generator for all other platforms. (Eventually we could have the cmake file generate the ARM build as well). But this seems like a good compromise, and it only requires adding one file.I'm working on a few example programs for PCs that use DaisySP (primarily a JUCE plugin, and a VCV Rack plugin) that will need to be able to build the library.
I've already tested creating a project with JUCE and DaisySP using cmake that was able to be up and running in Windows really quickly (though I still need to test on other OSes).
I'm open to others' thoughts on this, but this seems like a good approach for handling builds away from the Daisy Hardware (or ARM in general).