search

sudara / pamplejuce

A JUCE audio plugin template. JUCE 7, Catch2, Pluginval, macOS notarization, Azure Trusted Signing, Github Actions
https://melatonin.dev/blog/
MIT License
378 stars 37 forks source link

Provide clarity on the best-practices for the cmake/ submodule #57

Closed seclorum closed 9 months ago

seclorum commented 9 months ago

Hi Sudara,

Could you clarify something - currently pamplejuce has the cmake/ submodule, which is wired up for a project named "PampleJuce" - is it correct that the files in this submodule should be refactored to use the name of the target project, instead?

For example, I'm setting up PolarDesigner.pamplejuce to build our plugins - so I'm refactoring all PampleJuce->PolarDesigner references I can find. This kind of breaks with cmake/ as a submodule.

Could you add some docs to clarify this? Either:

a) the end-developer should clone the cmake submodule for their project and refactor it as needed, or b) cmake/ doesn't really need to be a submodule for the purposes of altering a PampleJuce template for the target project.

Make sense?

seclorum commented 9 months ago

Closing, just saw cmake/README.md .. duh ...

sudara commented 9 months ago

I will make this clearer — let me know if you had to touch anything in the cmake dir, the ideal is that you don't have to, all the config is done in the top level pamplejuce CMakeLists.txt

seclorum commented 9 months ago

Well, its clearer now that I understand that the cmake/ sub-module is the 'gravy' of the pamplejuce meal, and the .github/workflows/cmake_ctest.yml is the 'meat' .. I was just a bit confused as to why this was in a separate repo .. but I'm slowly grokking things.