Code::Blocks

To my intense annoyance I’ve wasted several days failing to get the projucer to link with llvm/clang on Windows, due to all sorts of VC++ nastiness. As a result I’ve decided to spend a few hours trying plan B, which is to switch to a MINGW build instead of VC…

So, to make that happen, I’ve quickly thrown together an Code::Blocks export target for the Introjucer. I’ve never been a fan of Code::Blocks, but I know that some people have talked about using it, so I’d really appreciate anyone who’s experienced with it trying this out. I’ve managed to build the juce demo with it, and it all seems to work… Feedback appreciated!

I’m doing all my Linux work in CodeBlocks, and it’s pretty useful. Remote debugging is fine, and some code completion, and a reasonable debugger once you get used to how stripped down it is.

Not a good time for a juce update, but I’ll try in a few weeks.

Bruce

I’ve only targeted a Windows build, but it’d be interesting to make it cross-platform… How does a Code::Blocks project work in terms of different platforms needing different libraries and settings?

Two things that i had to “fix” to get CodeBlocks to work (i need it know since i have a PC with Win7 and no admin right at work).

  1. it’s the chicken and the egg thing, there is no Codeblocks project in the GIT so i can’t build Introjucer to get other projects built with CB
  2. I had to add winmm to the library list to get the timeGetTime symbol to resolve

so far i got the Introjucer to build (using a Introjucer.exe i copied from a different PC) and I got a test standalone project created in Introjucer to build.

I’m using latest MINGW with gcc 4.7.2 and the latest nightly build of Codeblocks i found on the forums on their website.

Edit.

I get an error when building my own application, i saw this when i was using codelite

..\..\..\Standalone\JuceLibraryCode\modules\juce_audio_processors\..\..\..\..\..\Juce\modules\juce_audio_processors\..\juce_gui_basics\..\juce_graphics\colour\..\images\..\contexts\juce_GraphicsContext.h|30|fatal error: ../geometry/juce_Rectangle.h: No such file or directory|

It’s like GCC is not using relative paths correctly, this is how the file is compiled

mingw32-g++.exe -Wall  -O0 -std=gnu++0x -march=pentium4 -D__MINGW__=1 -D__MINGW_EXTENSION= -DCTRLR_NIGHTLY=1 -DJucePlugin_Build_Standalone= -DJUCER_CODEBLOCKS_34295A7F=1  -march=prescott   -I. -I..\..\..\Standalone\JuceLibraryCode -I..\..\..\..\Boost -I..\..\..\..\Source\Lua\luabind -I..\..\..\..\Source\Misc -I..\..\..\..\Source\MIDI -I..\..\..\..\Source -I..\..\..\..\Source\UIComponents -I..\..\..\..\Source\Core -I..\..\..\..\Source\Plugin -I..\..\..\..\Source\Application -I..\..\..\..\Source\Lua -I..\..\..\..\Source\Lua\lua -Ic:\mingw\lib\gcc\mingw32\4.7.2\include\c++ -Ic:\mingw\lib\gcc\mingw32\4.7.2\include\c++\mingw32 -Ic:\mingw\lib\gcc\mingw32\4.7.2\include  -c C:\devel\ctrlr\Source\Core\CtrlrIDManager.cpp -o obj\Debug\Source\Core\CtrlrIDManager.o
In file included from ..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/../../../../../Juce/modules/juce_audio_processors/../juce_gui_basics/../juce_graphics/colour/../images/juce_Image.h:30:0,
                 from ..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/../../../../../Juce/modules/juce_audio_processors/../juce_gui_basics/../juce_graphics/colour/juce_FillType.h:30,
                 from ..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/../../../../../Juce/modules/juce_audio_processors/../juce_gui_basics/../juce_graphics/juce_graphics.h:80,
                 from ..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/../../../../../Juce/modules/juce_audio_processors/../juce_gui_basics/juce_gui_basics.h:29,
                 from ..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/../../../../../Juce/modules/juce_audio_processors/juce_audio_processors.h:29,
                 from ..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/juce_audio_processors.h:4,
                 from ..\..\..\Standalone\JuceLibraryCode/JuceHeader.h:20,
                 from C:\devel\ctrlr\Source\Core\stdafx.h:74,
                 from C:\devel\ctrlr\Source\Core\CtrlrIDManager.cpp:1:
..\..\..\Standalone\JuceLibraryCode/modules/juce_audio_processors/../../../../../Juce/modules/juce_audio_processors/../juce_gui_basics/../juce_graphics/colour/../images/../contexts/juce_GraphicsContext.h:30:40: fatal error: ../geometry/juce_Rectangle.h: No such file or directory
compilation terminated.
Process terminated with status 1 (0 minutes, 3 seconds)
1 errors, 0 warnings (0 minutes, 3 seconds)

Thanks, I’ll post another version shortly, and will add a C::B project for the introjucer.

I seem to remember there used to be some kind of stupid length limit on the include paths… Maybe that’s what you’re hitting?

I think it’s too many relative paths the “Local JUCE folder” setting in Introjucer was set to “…/…/Juce”, once i set it to “c:\devel\juce” it works

They’re still using fixed-length strings in 2013!? Unbelievable!

MinGW is a good compiler and C::B is a nice IDE, but lot of people use Eclipse-CDT + MinGW as develop enviroment.
Would be nice to see an Introjucer exporter for Eclipse.
Regards

There seems to be an issue in the latest tip:

inline GUID uuidFromString (const char* const s) noexcept
{
    unsigned long p0;
    unsigned int p1, p2, p3, p4, p5, p6, p7, p8, p9, p10;

    sscanf_s (s, "%08lX-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X",
              &p0, &p1, &p2, &p3, &p4, &p5, &p6, &p7, &p8, &p9, &p10);

    GUID g = { p0, (uint16) p1, (uint16) p2, { (uint8) p3, (uint8) p4, (uint8) p5, (uint8) p6,
                                               (uint8) p7, (uint8) p8, (uint8) p9, (uint8) p10 }};
    return g;
}

sscanf_s() is not in MinGW, you can use sscanf() and it works

ok, thanks - will check that.

It would be great if we could have a MinGW Makefile export target as well, so you could build from command line in MinGW environment. That would also make it easier to integrated with Eclipse as well (makefile project type in Eclipse).

A MinGW Makefile export target would mean a whole load of extra IDEs could be used. This would be really great!

I shall leave that as an exercise for you lot, no time to do it myself!

A CodeBlocks exporter for the Introjucer would also make me really happy :slight_smile:

Hello Everyone,

I was trying to compile the introjucer in CodeBlocks with the included project file and I having the the following build error:

||=== The Introjucer, Debug ===|
C:\APPLICATIONS\juce\modules\juce_core\native\juce_win32_Network.cpp||In function 'void juce::MACAddressHelpers::getViaNetBios(juce::Array<juce::MACAddress, juce::DummyCriticalSection, 0>&)':|

C:\APPLICATIONS\juce\modules\juce_core\native\juce_win32_Network.cpp|379|error: no matching function for call to 'zerostruct(juce::MACAddressHelpers::getViaNetBios(juce::Array<juce::MACAddress, juce::DummyCriticalSection, 0>&)::ASTAT&)'|

||=== Build finished: 1 errors, 0 warnings ===|

the error: no matching function for call to zerostruct(juce::MACAddressHelpers::getViaNetBios(juce::Array<juce::MACAddress, juce::DummyCriticalSection, 0>&)::ASTAT&)

in the file: juce\modules\juce_core\native\juce_win32_Network.cpp

Any help and pointer will be well appreciated. Many thanks!

God blesses!!!

Best regards,
Sanyaade

[quote=“sanyaade”]Hello Everyone,

I was trying to compile the introjucer in CodeBlocks with the included project file and I having the the following build error:

||=== The Introjucer, Debug ===|
C:\APPLICATIONS\juce\modules\juce_core\native\juce_win32_Network.cpp||In function 'void juce::MACAddressHelpers::getViaNetBios(juce::Array<juce::MACAddress, juce::DummyCriticalSection, 0>&)':|

C:\APPLICATIONS\juce\modules\juce_core\native\juce_win32_Network.cpp|379|error: no matching function for call to 'zerostruct(juce::MACAddressHelpers::getViaNetBios(juce::Array<juce::MACAddress, juce::DummyCriticalSection, 0>&)::ASTAT&)'|

||=== Build finished: 1 errors, 0 warnings ===|

the error: no matching function for call to zerostruct(juce::MACAddressHelpers::getViaNetBios(juce::Array<juce::MACAddress, juce::DummyCriticalSection, 0>&)::ASTAT&)

in the file: juce\modules\juce_core\native\juce_win32_Network.cpp

Any help and pointer will be well appreciated. Many thanks!

God blesses!!!

Best regards,
Sanyaade[/quote]

What version of GCC? You’d need a recent one, the old versions of mingw were very buggy.

Actualy that happens to me too, i had explicitly call zeromem instead of the templated JUCE version, for some reason mingw doesn’t like that.

That code has been in there for ages, and I’ve definitely compiled it with mingw. I can only guess it’s a GCC weirdness in older versions?

Not possible i used the latest possible windows gcc 4.7.2.1, maybe the new versions screws this up, but i never used anything below 4.6

Well, just to make sure, I compiled the juce demo again with mingw 4.7.2, and yes, it compiles just fine. The code itself is 100% legit.

I really do think you must be accidentally using an old compiler version, there’s no other reason why it’d do that. You should add “–version” to your build flags to double-check,