Some "must be there" things


#1

i think they must be there, but that’s just me

  • jucer cannot add extensions to binaries (with multiple configurations i get all DLL files, and i want some configurations to be EXE files), also when i add my own extensions i get doubles like file.dll.dll or file.exe.dll
  • with multiple configurations you can’t link with different libraries (debug/release libraries) so i have to link all configurations to one library
  • it would be nice if the project type (gui/console/lib) would be a per-configuration selection

#2

I don’t really think that’d work very well - if a single project could have configurations to build completely different types of object, I’m sure that’d lead to all kinds of conflicts when generating the projects… If you’re building an exe and a dll, shouldn’t these just be different projects?


#3

no, since it’s exactly the same code (vst plugins/standalone plugin), the only difference is the preprocessor directive JucePlugin_Build_Standalone that includes a small piece of code that launches the Standalone window.
It works perfectly within one project in VS and XCode, so i don’t see any potential for conflicts, same include dirs same linker flags.

i have about 20 plugins right now, so creating seperate projects means 80 projects (mac + win) and 120 projects if i add linux. This means building each one everytime i change the common code, witch means rebuilding juce witch takes some time. Rebuilding all those projects will take some time as you can imagine.

It would be nice to be able to host multiple projects within a single project and do builds from there, i do that but i created my own solution in VC for this.

pretty please


#4

Please no grovelling!

Surely it’s not 80 jucer projects, it’s 20 for the plugins, and another 20 for the exes? I’m only suggesting that it’s fiddly to have a project that creates both an exe and a dll, because they’re fundamentally different things…