Collection repository #1
Comments
|
I just started testing around if this is easy / possible at all:
I think "releases" is not that bad. But another suggestion: rename it to "Chowdhury-Plugins" since this sounds like a plugin collection of you and basically it contains all your plugins so would make sense. Also, an idea for the releases: |
|
Ooh, thanks for taking a look at this! Yeah, the submodule thing is kind of tricky, since some of the plugins are on older versions of JUCE, that may not be immediately compatible with the plugin code. For using the repository in a build pipeline, I bet it might be okay, since we could only clone the submodules for the plugin we want to build in that run of the pipeline. Another idea could be to use a different package manager like CPM, perhaps in tandem with git submodules. That name suggestion sounds good as well, although I think I would prefer Updating submodules in the repo should be pretty straightforward. I'm not sure how easy it is to automate creating GitHub releases, but I imagine that should be pretty do-able as well. I should have some time on Thursday, so I can take a closer look then. Thanks, |
|
Okay, so I was able to do some testing in the So from here, I think the process will look like this:
|
Some linux distributions don't allow internet access during build time. However when building all plugins anyway cloning with all submodules in the first / downloading step should be fine.
This is also okay. Just asked about it in case it could be optimized. Maybe one day, but I don't think this is a dealbreaker. So I had a look at your v2 branch and see you currently build using bash scripts. Would recommend to stay with a standardized (and the current cmake) build system. This is what most linux build tools support ootb, have their settings for preconfigured, can automatically handle and doesn't force the dependency on bash. Would be nice to have all the plugins integrated into one cmake project and only set the build targets if not all plugins should be built. Something like, in the meta repos base dir: to build all targets/plugins. to build only CHOWTapeModel and ChowMatrix without the standalone. Do you think this could be possible this way, using only cmake / no bash? I tried that in my repo linked above. Used cmakes |
|
Cool, yeah I think we've got a good path forward starting from here. I think I would like to keep the bash script interface, since I think it integrates better with GitHub Actions, and makes it easier to generate installers for Windows/Mac, but having a CMake interface would certainly be nicer for building locally, and probably for most packaging systems as well. I'll have to do some testing (might not be able to until later this week), but I think the top-level CMakeLists.txt should look something like this: cmake_minimum_required(VERSION 3.15)
project(ChowDSP-Plugins VERSION 2.0.0)
# This should fix the build target conflicts
set(ALLOW_DUPLICATE_CUSTOM_TARGETS TRUE)
# This plugin will be configured by default.
option(BUILD_CHOWTAPE "Build the ChowTape plugin" ON)
if(BUILD_CHOWTAPE)
message(STATUS "Configuring build for ChowTape")
add_subdirectory(plugins/ChowTape)
endif()
# This plugin hasn't been released yet, so it will NOT be configured by default.
option(BUILD_BYOD "Build the BYOD plugin" OFF)
if(BUILD_BYOD)
message(STATUS "Configuring build for BYOD")
add_subdirectory(plugins/BYOD)
endif()Does that seem reasonable? |
|
I pushed your suggested CMakeLists.txt changes to my repo now and tried building that. It seems to work when only building one plugin at a time but with multiple ones there are still conflicts, here for example when I try to configure build of CHOWTAPE and CHOWCENTAUR: |
|
Ah yeah, it looks like the JUCE targets are conflicting... I wonder if calling By the way, sorry I've been pretty swamped this week, but I will definitely have some time to dig into this more fully on the weekend. Thanks! |
Unless I didn't use it correctly, doesn't seem to help :/
No problem. Thank you :) |
|
Hey! So I was able to spend some time on this today. It looks like what we've been looking for in the CMake world is not That said, with CMake external projects, it might be a bit redundant to be using Git submodules, since the external projects can just as easily download the source using the branch/commit specified in the metadata file. Anyway, just something to think about... |
Hi, yeah this looks good, will test it later.
Yes, building only plugins or only standalone should be possible.
Remember: Some build systems don't allow internet access during build time. Not sure how they handle this |
|
Hm tested this with only building chow tape and it currently fails while trying to install JUCE. Still have to disable this install step I guess. |
|
I think I found a way around that by using STEP_TARGETS. This works now, can build all plugins or only selected ones. Nice :) |
|
Nice! Yeah, For only building only standalone targets, I was able to start on this CMake config today. Haven't been able to test it much, plus it's a lot more repetitive that I'd like, but maybe it's a start: option(BUILD_STANDALONE_TARGETS_ONLY "Build only standalone targets" OFF)
option(BUILD_BYOD "Build the BYOD plugin" ON)
if(BUILD_BYOD)
message(STATUS "Configuring build for BYOD")
set(BYOD_DIR "${CMAKE_SOURCE_DIR}/plugins/BYOD/BYOD")
if(BUILD_STANDALONE_TARGETS_ONLY)
ExternalProject_Add(BYOD_Standalone
SOURCE_DIR "${BYOD_DIR}"
CMAKE_ARGS "-DBUILD_RELEASE=ON"
BUILD_COMMAND ${CMAKE_COMMAND} --build . --config Release --target BYOD_Standalone
STEP_TARGETS build
)
else()
ExternalProject_Add(BYOD_All
SOURCE_DIR "${BYOD_DIR}"
CMAKE_ARGS "-DBUILD_RELEASE=ON"
BUILD_COMMAND ${CMAKE_COMMAND} --build . --config Release --target BYOD_All
STEP_TARGETS build
)
endif()
endif() |
|
I just made test builds to compare: building all targets (default) vs. building only LV2+VST3. Maybe it is not even worth it, it makes a much smaller difference in build time than I thought it would. Can still keep this in the back of our head and think about it later for optimization, but I wouldn't see this as a dealbreaker and think it would be okay to not have this option for the initial release. So I think it is fine now from my side. When you are ready too you can merge it with your github workflows stuff and make a first release. |
|
Yeah, that's a good point: most of the plugin code is built as a static library, which is then shared between the different plugin format wrappers, so adding/subtracting a plugin format won't affect the built time too much. I think the next steps from here are:
I should have some time this weekend to hopefully get through the first three steps. |
|
Alright! It looks like the nightly build script is now updating the submodules in this repo automatically! I'll try to get a few more tests in over the next couple of days, but it looks like the basic workflow is in place. |
|
I tried building that with flatpak and it fails at cloning this repo. Edit: |
Cloned from jatinchowdhury18/AnalogTapeModel#239:
@Bluezen wrote:
@jatinchowdhury18 wrote:
The text was updated successfully, but these errors were encountered: