I am having trouble building juce on Dev-Cpp (4.9.9.2). I have tried juce versions 1.30, 1.32 and 1.36, all have the same problem. Dev-Cpp has trouble finding several of the include files, for example:
E:\libs\juce\juce_1_36\src\juce_appframework\gui\graphics\fonts\juce_Typeface.h …/…/…/…/juce_core/containers/juce_ReferenceCountedObject.h: No such file or directory.
I have been able to compile the library by manually changing all the troublesome include statements, but: is this a known problem, or is there something wrong in my environment?
It seems to be include statements containing “…/…/…/…/” that cause the trouble :?
That’s the same version I’ve got here, and it builds fine. Have you got the latest version of the compiler? Maybe some older gcc versions don’t understand relative pathnames (that sounds a bit unlikely to me though).
One other possibility - I normally have my code in c:\code\juce. If you’ve got it in some deep folder with a long pathname, then maybe when it tries to append the relative pathname on the end, this exceeds some hard-coded string length in the compiler.
Actually, moving the library to a different folder with a shorter path name did the trick, it compiles fine now
I have had errors on too long path names on Windows before, think there is a 256 character limit. Not sure if it is windows or the compiler in this case (gcc version is 3.4.2., WinXP SP2)
What’s strange was that when compiling the demo application I could use the original, unchanged files, no such errors then.
[quote=“ThomasB”]Actually, moving the library to a different folder with a shorter path name did the trick, it compiles fine now
I have had errors on too long path names on Windows before, think there is a 256 character limit. Not sure if it is windows or the compiler in this case (gcc version is 3.4.2., WinXP SP2)
What’s strange was that when compiling the demo application I could use the original, unchanged files, no such errors then.
Thanks, gonna start using the library now 8)[/quote]
Good grief, that’s pathetic on somone’s part. Obviously what they’ve done is used a fixed-length string, probably 512 chars (max filename length on windows). But of course a valid relative path can be much longer, and they’ve not bothered to parse out the “…/” bits. Doh.
I thought the max limit for an absolute path+filename in NTFS5(4?) was 2048 characters (maybe 16k?)? I have some of my organized directories getting near that…
I have no idea, just remembered vaguely some error message I got once, when unzipping some files. In this case the path length seems to be the reason, could just as well be a limitation in the compiler.
