2> juce_VST_Wrapper.cpp
2>c:\devel\juce\modules\juce_core\zip/juce_ZipFile.cpp(91): error C2780: 'Type juce::jmin(const Type,const Type,const Type,const Type)' : expects 4 arguments - 2 provided
2> c:\devel\juce\modules\juce_core\system\../maths/juce_MathsFunctions.h(119) : see declaration of 'juce::jmin'
2>c:\devel\juce\modules\juce_core\zip/juce_ZipFile.cpp(91): error C2780: 'Type juce::jmin(const Type,const Type,const Type)' : expects 3 arguments - 2 provided
2> c:\devel\juce\modules\juce_core\system\../maths/juce_MathsFunctions.h(115) : see declaration of 'juce::jmin'
2>c:\devel\juce\modules\juce_core\zip/juce_ZipFile.cpp(91): error C2782: 'Type juce::jmin(const Type,const Type)' : template parameter 'Type' is ambiguous
2> c:\devel\juce\modules\juce_core\system\../maths/juce_MathsFunctions.h(111) : see declaration of 'juce::jmin'
2> could be 'size_t'
2> or 'juce::int64'
2>c:\devel\juce\modules\juce_core\zip/juce_ZipFile.cpp(116): warning C4018: '>=' : signed/unsigned mismatch
2>c:\devel\juce\modules\juce_graphics\image_formats\pnglib/pngrutil.c(3146): warning C4310: cast truncates constant value
Also it’s now impossible to house multiple different type projects in the same directory. I have 3 JUCE projects for AU/VST/Standalone and since the plugin parameters have been moved to the global AppConfig.h i need to save the VST/AU project the last to build a release of all of them (if i save the standalone last the plugins won’t work).
I noticed some WeakReference changes that needed a bit of a code change (had to remove the functions that were used to fetch the master reference, and add a friend class).
The new Introjucer hides it’s titlebar when it starts (the first visible on-screen element is the menu), it goes back to normal after i resize it or do a minmize/maximize using the right click commands on windows (dunno if this is the intended behavior).
I just found something weird, i was keeping the JuceLibraryCode directory in my SVN but now everytime i save the project in Introjucer it looks like the .svn/ directory gets removed (at least the .tmp directory and .props directory are gone). Dunno if that’s what should happen and i’m just beeing an idiot for keeping that folder in my repo ?
I’m loving the new architecture, great job.
Agghh, you’re probably using Subversion or CVS or something? When saving, that folder will get deleted and rebuilt, so if you’re using one of the crappy old CVS systems that creates hidden folders everywhere, then it’ll get rid of them as well. (Not a problem with GIT, of course). Damn. I guess I’ll have to come up with some kind of system to avoid removing all the stupid hidden files.
But no, you’re not stupid - the whole idea is that you probably do want to keep that folder under version control.
If you’re building a black list of files that should not be removed from the JuceLibraryCode folder by the IntroJucer, please include “CMakeLists.txt”.
We are already using cmake to build our juce projects, and our plan to survice the juce quake was to use the new IntroJucer to populate the JuceLibraryCode folder with the required module files, and then use cmake to generate the project. It’s a common convention to put the CMakeLists.txt file right next to the sources.
Maybe it would be better to let the IntroJucer only touch files that it has copied there, or just detect its generated files by the naming conventions? Other users might have other good reasons to have their own files in the JuceLIbraryCode folder…
Thanks, I’ll certainly add CMakeFiles.txt to the white-list.
It’d be nice to only delete files that the introjucer created, but I can’t think of a straightforward way to do that. There’s no way to look at any file and figure out whether it was created by the introjucer or not, so I think a solution like that would have to involve keeping some kind of record of files that were created, which has other ways in which it could fail.
Of course this is why it makes sense to check the folder into source-control… but of course that only works if you have a decent source control system like GIT that doesn’t scatter hidden files all over the place and then get confused when something happens to them. That was one of my main reasons for loathing SVN - atom, you really really should move to git or mercurial.
