Whenever i try to compile, even from a fresh install of windows and dev-cpp [ Beta 5 ] I always get a single error:
C:\Dev-Cpp\juce\src\juce_core\containers\juce_Array.h ../threads/juce_CriticalSection.h: No such file or directory.
the juce folder was unzipped to C:\Dev-Cpp\Juce\ , so its not the root filepath problem with gcc.
Nvm, I fixed it simply by adding it the the compilers search path and removing …/threads/ , which doesnt fix it, just goes around it…
Bleedin heart liberals!
STOP USING DEV-CPP
your problems will disolve!
goes back to sleep
Although he is obviously tired, I agree with him. DevC++ is very old and at at all complient compared to other free things that are available.
Hi,
I could compile Juce with Code::Blocks IDE (importing DevCPP project file).
IMHO, Juce’s #include “…/…/” style is problemmatic here.
I ended up including every directory to project:
Maybe Boost style could be better? Then we only add Juce’s
master path as include directory.
ie. Instead of:
#include “…/io/files/juce_FileOutputStream.h”
#include “…/threads/juce_ScopedLock.h”
#include “…/basics/juce_SystemStats.h”
this:
#include “juce/src/juce_core/io/files/juce_FileOutputStream.h”
#include “juce/src/juce_core/threads/juce_ScopedLock.h”
#include “juce/src/juce_core/basics/juce_SystemStats.h”
Just a thought…
–
Regards,
Hakki Dogusan
That’s ridiculous - so it can’t find the relative path to juce_CriticalSection.h, but it can find the thousands of other relative paths in there? And it compiles for me in devcpp with no problems. You sure you’ve not got some other path in your search path that’s confusing it?
[quote]IMHO, Juce’s #include “…/…/” style is problemmatic here.
I ended up including every directory to project:
Maybe Boost style could be better? Then we only add Juce’s
master path as include directory.
ie. Instead of:
#include “…/io/files/juce_FileOutputStream.h”
#include “…/threads/juce_ScopedLock.h”
#include “…/basics/juce_SystemStats.h”
this:
#include “juce/src/juce_core/io/files/juce_FileOutputStream.h”
#include “juce/src/juce_core/threads/juce_ScopedLock.h”
#include “juce/src/juce_core/basics/juce_SystemStats.h”
[/quote]
I totally disagree. The way it’s done now requires no extra search path setup at all - you include juce.h, and everything else just comes along with it. Dead simple, with no danger of picking up the wrong version of a file just because there’s a copy somewhere else in your search path, etc… And it works perfectly well on MS and GCC compilers, so why the problem with what you’re using?
Hi,
When I see “That’s ridiculous…I totally disagree.”, I thought
there should be something wrong in my setup! And I tried another way
to compile Juce.
(WinXP, Code::Blocks-1.0 Revision:2723 IDE, vc8, Juce-1.35;
previously I was trying with MinGW32)
IDE->File->Import Project->MS Visula Studio Solution
Select: build/win32/vcexpress/JUCE.sln
IDE asks: Do you want the imported projects to use the default compiler?
Click: NO (since default compiler is gcc)
IDE asks: Dou you want the import all configurations (e.g.Debug/Release) from the imported projetcs?
Click: YES
Select Compiler: (I choosed vc8 here)
…after IDE imported
Click: Build
That is it! It builds :))
Repeated same for demo and jucer projects…
BIG SURPRISE: I can use Turkish characters in demo now!!!
(I’ll re-check mingw setup)
–
Regards,
Hakki Dogusan
Hi,
I just downloaded JUCE tonight and ended up with the same kind of errors as yours.
I figured out what the problem is. The “…/…/…/” style is indeed the cause of it.
The reason is it’s breaking your OS maximum path name length limitation (260 chars for Win XP as explained here).
That is why relative include directives has always been a bad habit. Because at some point you are ending up with “Some/included/files/…/…/which/include/…/…/some others/…/…/…/and/so/on/…/…/…”. You can see it can easily break the limitation. Have a try with JUCE. Juste put it in your root directory (/ or C:) and it will compile fine. Put it in a 6 level subdirectory with a few long names it will break.
It should be replaced with a fully specified path configured by a configure script or a preprocessor directive I think.
I must admit I am a bit disappointed to find such an ugly 
mistake here. I hope it will be fixed ASAP so I can use JUCE :).
[quote=“beatkyo”]Hi,
I just downloaded JUCE tonight and ended up with the same kind of errors as yours.
I figured out what the problem is. The “…/…/…/” style is indeed the cause of it.
The reason is it’s breaking your OS maximum path name length limitation (260 chars for Win XP as explained here).
That is why relative include directives has always been a bad habit. Because at some point you are ending up with “Some/included/files/…/…/which/include/…/…/some others/…/…/…/and/so/on/…/…/…”. You can see it can easily break the limitation. Have a try with JUCE. Juste put it in your root directory (/ or C:) and it will compile fine. Put it in a 6 level subdirectory with a few long names it will break.
It should be replaced with a fully specified path configured by a configure script or a preprocessor directive I think.
I must admit I am a bit disappointed to find such an ugly 
mistake here. I hope it will be fixed ASAP so I can use JUCE :).[/quote]
Ugly mistake??? Relative paths are the cleanest, most portable way of doing this. Using a configure script, or making every user set up their own include paths would be ugly.
The “ugly mistake” was when the compiler writers didn’t actually bother parsing the filename, but just concatenated the whole thing together and copied it to a fixed-length array without even showing a sensible error message when it was too long. No way am I going to make my code less elegant because of such a dumb-ass mistake (which is fixed in all the decent compilers anyway).
(And of course if they’d been using juce::File they’d never have had the problem in the first place…)
Hum I think you are right actually because microsoft compiler can handle relative path. It is a shame gcc does not. BUT I think gcc is a descent compiler.
Anyway relative path or not I’ve always been told in high school to never use this kind of include. I can’t remember why exactly but It must have been quite important as only seeing it make me think “DON’T DO IT !!!” (not against you just my own feeling here :p).
[quote=“beatkyo”]Hum I think you are right actually because microsoft compiler can handle relative path. It is a shame gcc does not. BUT I think gcc is a descent compiler.
Anyway relative path or not I’ve always been told in high school to never use this kind of include. I can’t remember why exactly but It must have been quite important as only seeing it make me think “DON’T DO IT !!!” (not against you just my own feeling here :p).[/quote]
Yes, GCC is a decent compiler, and the newer versions don’t have this bug, AFAIK.
You were probably told never use a relative path to include something from a different project, which is good advice. But for a set of files with a fixed arrangement to each other, like juce’s headers, it’s exactly the right way to do it.
I am using the latest MinGW release.
Yes, but they don’t even use gcc4 yet, do they?
That I must admit I do not really know. I’wiil investigate this and will look toward cygwin
Lol, I posted this awhile ago…looks like it started a mini flame war…
Hi,
(Juce-1.39, Mingw, WinXP, Code::Blocks-1.0 Revision:3094 IDE)
Juce is compiling with the above configuration.
You can get Code::Blocks project files from:
http://www.dynaset.org/dogusanh/download/juce_codeblocks.zip
Hope it helps somebody…
–
Regards,
Hakki Dogusan
[quote=“hd”]Hi,
(Juce-1.39, Mingw, WinXP, Code::Blocks-1.0 Revision:3094 IDE)
Juce is compiling with the above configuration.
You can get Code::Blocks project files from:
http://www.dynaset.org/dogusanh/download/juce_codeblocks.zip
Hope it helps somebody…
–
Regards,
Hakki Dogusan[/quote]
Hakki,
It has helped me. 
Thank you for sharing.
Cheers,
Miquel.
Thank you hd!
That’s the cure!
Julian (if you are here).
Maybe it’s the time to support the newer IDE “Code::Blocks” instead of DevCPP?
You’re probably right, though I’ve never actually tried code::blocks. Will have a look when I get chance.
[quote=“mahtazz”][quote=“hd”]Hi,
(Juce-1.39, Mingw, WinXP, Code::Blocks-1.0 Revision:3094 IDE)
Juce is compiling with the above configuration.
You can get Code::Blocks project files from:
http://www.dynaset.org/dogusanh/download/juce_codeblocks.zip
Hope it helps somebody…
–
Regards,
Hakki Dogusan[/quote]
[/quote]
Builing Jucer project with CodeBlocks I get:
:: === Jucer, gcc-debug ===
..\..\src\model\components\..\components\jucer_ComponentTypeHandler.h:45: warning: `class ComponentTypeHandler' has virtual functions but non-virtual destructor
..\..\src\model\components\jucer_ComponentTypeHandler.cpp:54: error: 'const class std::type_info' has no member named 'raw_name'
..\..\src\model\components\jucer_ComponentTypeHandler.cpp:126: error: 'const class std::type_info' has no member named 'raw_name'
:: === Build finished: 2 errors, 1 warnings ===
Do you know if there were changes in the source code since you created the project?
Thank you in advance.
