Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JUCE as a submodule #335

Merged
merged 1 commit into from Apr 5, 2022
Merged

JUCE as a submodule #335

merged 1 commit into from Apr 5, 2022

Conversation

haenkel
Copy link
Contributor

@haenkel haenkel commented Apr 4, 2022

The cmake addition is great (thanks @showlabor)!
I'd like to suggest making JUCE a submodule though.

The way it is included via CPM now means it downloads around 250Mb
every time a new build folder is created or JUCE gets updated.
Adding it as a submodule with depth1 you end up with aprox 60Mb once,
updates are incremental and it's independent from the build folder.

This will also speed up potential pipeline builds.

The cmake addition is great (thanks @showlabor)!
I'd like to suggest making JUCE a submodule though.

The way it is included via CPM now means it downloads around 250Mb
every time a new build folder is created or JUCE gets updated.
Adding it as a submodule with depth1 you end up with aprox 60Mb once,
updates are incremental and it's independent from the build folder.

This will also speed up potential pipeline builds.
@showlabor
Copy link
Contributor

Thanks for giving the cmake option a try! I'm glad that it does not only work on Debian :-)
I chose the "JUCE via CPM" way mainly because it does not interfere with the current projucer based build system. As long as cmake is not the main build system I would rather not pull in a 60 MB submodule that is not even used in the still canonical build process.

But, once the cmake build system is ready and tested the submodule approach should be considered. I'm a bit undecided, though, since both methods have their pros and cons.

@haenkel
Copy link
Contributor Author

haenkel commented Apr 5, 2022

The submodule unpacks to 60 Mb but downloads around 12 or so (way less than 250 and only once).
It still doesn't interfere with the projucer build script.
(Only if you did a projucer build before,
you'd have to delete the JuceLibraryCode folder first before going cmake,
but thats unrelated to the submodule and is true for both methods.)

Your CMakeLists.txt should actually work on all OSes (note: I changed the terminal commands in the readme
which call the default compiler for the given OS (gcc for most gnus, msvc for win, clang on mac) instead of make).

What may break things is that we both bumped Juce to 6.1.6
(it did for some distros see #334).

@showlabor
Copy link
Contributor

OK, I'm convinced.
(BTW, thanks for polishing the CMakeLists.txt files and related additions to the README_cmake.md!)

@baconpaul
Copy link
Contributor

The cmake is super lovely. I will try and find some time this afternoon to update the azure pipelines file to work with it also.

also now it’s on cmake I can do a clap build which is very exciting! Thanks!

@asb2m10
Copy link
Owner

asb2m10 commented Apr 5, 2022

Thanks for this. Yes this makes sense, all dependencies should be a submodule....

Hi @baconpaul , I'm planning to migrate to GitHub Action (I already got the built running) since it works out of the box with the platform.

@asb2m10 asb2m10 merged commit 3631907 into asb2m10:master Apr 5, 2022
@haenkel haenkel deleted the sub branch April 5, 2022 16:54
@haenkel
Copy link
Contributor Author

haenkel commented Apr 5, 2022

Over in the surge discord a few more people test-compiled the latest changes and in total we now have succesful cmake-builds
with: debian, ubuntu (gcc and clang), mac m1(clang) and windows 10(msvc).
So yeah @showlabor , your cmake port works on all major OSes.
(lots of warnings though but no errors).

@baconpaul
Copy link
Contributor

Awesome and yup, if i was starting from scratch i'd use actions too. If you find them unwieldy though we have lots of pipelines files which work nicely for juce + cmake.

Oh also if you are interested and have an apple id, i have a script which signs and notarizes on macOS which would work for you once your cmake build is running.

Finally i did a test clap build today. Not quite working (not dexed fault I don't think) but got it to load in BWS.

So this is all around great!

@baconpaul
Copy link
Contributor

oh and hi @asb2m10 :)

@showlabor
Copy link
Contributor

we now have succesful cmake-builds with: debian, ubuntu (gcc and clang), mac m1(clang) and windows 10(msvc). So yeah @showlabor , your cmake port works on all major OSes. (lots of warnings though but no errors).

Oh, that's great, thanks for the feedback :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants