We created a PoC that shows how you can use the JUCE modules via Buckaroo:
The advantage of doing this is that you can easily integrate other Buckaroo packages (e.g. Boost, Eigen) into the project, using one cohesive tool.
However, I’m not sure I understand what you mean by “Buckaroo has already some IDE support”, so I might be missing something.
It is possible to take a Buckaroo project structure and generate an IDE project from it. This will give you auto-complete, refactoring and context-aware navigation, etc.
We think it is important that developers can use their preferred IDE with Buckaroo.
My main question is how do you see the use of Buckaroo alongside Projucer? I was imagining we’d use JUCE as we do currently, managing projects via Projucer, and pull in extra dependencies separately (in this case using Buckaroo), i.e. have 3rd party JUCE modules as Buck packages.
My understanding of JUCE is the module format is quite simple (I like it!) but also inflexible. It will be infeasible to port other projects to the JUCE format, but porting JUCE to something more general (e.g. Buck) is quite straight-forward.
So I think the only way to integrate non-JUCE packages is to not use Projucer.
I could be wrong here though, can someone more knowledgeable weigh in?
Is it possible for Buckaroo to refer to just part of a git repo?
There are two aspects to this: the dependency-graph and the build-graph.
Buckaroo will always fetch the entire folder from Git. We made this efficient by using caches and shallow clones. When you come to build, however, we only build the modules that you actually depend on.
In other words, there is some redundancy in the dependency-graph (we sometimes fetch code you won’t actually build), but there is zero redundancy in the build-graph (you only ever build the code you actually use).
We would like to improve this in the future, but given that compilation is the more expensive bit, this works well for now. Git “partial clones” are still experimental and not supported by GitHub.
However that would mean a single repo (JUCE) having multiple Buckaroo packages and for each one to be pulled independently of each other but without essentially having to rely on the back end just cloning the entire repo multiple times.
To clarify how it would work, we would have one package (JUCE) that contains multiple targets (juce_core, juce_graphics, etc.)
We would only clone this once per machine since we use a cache.
It would be possible to split the JUCE package into multiple packages, but this makes maintenance more difficult. For one, we would have a different folder structure to JUCE upstream. Atomic releases would also no longer be possible.