I would like to have JUCE in a library project, which I can embed in my own project, instead of have to fiddle around with the projucer, which never will be able to let me choose all needed project features and dependencies.
For my current plugin project I am trying hard to use the projucer, though its limitations give a hard time. Especially if the projects need to be generic and modular.
Now: I am usually embedding AAX wrapping and signing, as well as packaging the plugin into .pkg resp. .msi installer into the plugin project itself. Since I don’t see an option to include external projects I try to do the same as a build step, unfortunately now the projucer generates separate Xcode targets for all plugin formats, and places the build step in all of them. Why would that be?
For Visual Studio however I don’t see any option to embed a WIX installer project into the solution. How is this intended?
Thanks & cheers,
And more: The projucer injects settings into the Xcode targets. Thats wrong. It should inject the settings as project settings. This would also allow to have those settings in the “plugin (All)” available. Beneath the fact that those redundant setting distribution across all targets can be avoided. (Those few settings that are really for a certain target should be injected in the target of course).
Now the reason to be so pedantic is that the “plugin (All)” post build step needs those settings.
Now, since I have to fiddle around with the projucer its project file must go into an SCM. And I have to check it, but its partly unreadable: Wouldn’t it make sense to use xml tags instead of xml attributes for multi line settings like the additional build steps; (search) folder lists, etc?
I am not sure if soliloquising is an indication of being completely out of line or if you just don’t care.
Its remarkable how much effort you put in reinventing the wheel and circumvent already existing and proven ways of project organisation:
My project consists of actual subproject, which by using the Projucer I really can’t organize in other ways than putting all source files into the projucer project. Now there are no compile option for platform dependent source files. Yes there are ways around this, but I really don’t see the advantage of having to use the projucer, just because you can’t put JUCE itself into a project which can be referenced the usual way from my project that I maintain without the interference from some insufficient Meta project.
Now there are suggestion of using my own JUCE modules, but there is no way of defining an acceptable module path. They can’t live in the JUCE repository. And locally created symbolic links are not helpful because the project should compile right after checkin it out of the SCM.
How is it intended to use platform dependent source file in a projucer maintained project?
We certainly do care, it’s just that your questions are quite broad and the exporters are all being worked on at the moment. The response to most of your suggestions is simply “yes, we’ll look at that”.
Can you have the following directory structure?
- JUCE (git submodule)
- Your JUCE modules (with platform specific filenames) (also a git submodule?)
No symbolic links and it will compile straight out of an SCM.
mhhh, PACE (and therefor at least AAX) requires compiling at least a .c file and some headers from the PACE framework. The path to the framework is different for macOS and Windows. How can this be achieved with projucer?
Meanwhile I regret trying to maintain my projects with projucer. Its probably way less annoying and time consuming updating my JUCE library sub project so it continues to compile with any JUCE update and just maintain real IDE projects.
If your goal is to reuse/combine IDE settings for your projects, instead of using Projucer you may find “.xcconfig” files and Property Sheets (".props" files) quite useful for Xcode and Visual Studio, respectively.
Yes, thanks yfede,
thats actually part of how I organized development. However since there are a lot of changes between JUCE versions and no real release notes explaining the differences it was always a pain in the neck to maintain my juce based projects. So I decided to give projucer a try again, but meanwhile ended up spending way more time working around its shortcomings.
I understand that for some plugin projects it might be sufficient, but as soon as there is some modularization, generic solution and build intergration involved it actually resists completely.
In any case its MACRO orgy is unrivalled.
JUCE team - I think some sort of acceptance of CMake into the Projucer would help the situation out a lot.
I get the resistance to having an IDE project generator generate files for another IDE generator, but unless the Projucer project format (which seems like a side project to JUCE itself, despite being its heart) suddenly makes the years of progress CMake has made, attempting to use Projucer for large-project management that pulls in lots of non-JUCE libraries (which are usable with only 1-2 extra lines in CMake) is infeasible.
Yep, we hear you - lots of people have been asking for cmake support, we’re considering it seriously.