Export to Codeblocks option not working

Hi,

I'm infinitely new to C++, but have managed to compile before. The thing is i'm using Codeblocks. Because I can't log in to Microsoft periodically to validate my demo copy of  Visual Studio, so it's expired. And whenever I set Juce to create a target for Codeblocks, it does not list Codeblocks in the little list. Could I be doing something wrong?

Hi,

What little list? Do you mean the one that appears when you click on "Save Project and open in IDE"? I think that's not working for Code::Blocks (it doesn't know where you installed it to) so you just have to "Save Project" and then launch Code::Blocks manually.

Thanks for the response, I found the Codeblocks version of the Introjucer too and it compiled fine.

But when trying to compile my first gui app I get the "no such file" error for #include "contexts/juce_LowLevelGraphicsSoftwareRenderer.h"

Consequently if I set the extra compiler flags i get a "no such file" error for #include "app_properties/juce_ApplicationProperties.h"

Do I need to point Codeblocks to Juce or..?

Are your JUCE module paths in the Introjucer all correctly set for the Code::Blocks exporter?

That sounds a bit steep for my knowledge. But I did set the module path on the intro screen (to point to the main modules filder) , also set it up for Codeblocks Windows. Setting extra compiler flags was actually an android fix, the next button up in the intro screen.

What I did not try tho is setting extra compiler flags for all the folders in the Juce lib. So I will try that in a bit.

It's actually square one again "contexts/juce_LowLevelGraphicsSoftwareRenderer.h"

 

Using win7 64, compiling with mingw (default)

That's a relative include path. Any compiler should resolve it without needing any special path settings.

Do you actually have the rest of the juce library files in the right place? i.e. does the file that it's looking for actually exist, or do you have a messed-up source folder?

It happened twice on a fresh install. So the Juce folders are intact.

I'm not suggesting you didn't install it properly.

But if you actually look at that include file on your disk, is there actually a target file with the correct name in the correct relative folder? Because I can't believe that include statement could possibly fail if the target file is where it should be.

From what I can gather, From the Codeblocks right click menu "contexts/juce_LowLevelGraphicsSoftwareRenderer.h" points an existing file in the juce modules folder as expected. Afaik, there are no others, right?

 

/*
  ==============================================================================

   This file is part of the JUCE library.
   Copyright (c) 2015 - ROLI Ltd.

   Permission is granted to use this software under the terms of either:
   a) the GPL v2 (or any later version)
   b) the Affero GPL v3

   Details of these licenses can be found at: www.gnu.org/licenses

   JUCE is distributed in the hope that it will be useful, but WITHOUT ANY
   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
   A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

   ------------------------------------------------------------------------------

   To release a closed-source product which uses JUCE, commercial licenses are
   available: visit www.juce.com for more information.

  ==============================================================================
*/

#ifndef JUCE_LOWLEVELGRAPHICSSOFTWARERENDERER_H_INCLUDED
#define JUCE_LOWLEVELGRAPHICSSOFTWARERENDERER_H_INCLUDED


//==============================================================================
/**
    A lowest-common-denominator implementation of LowLevelGraphicsContext that does all
    its rendering in memory.

    User code is not supposed to create instances of this class directly - do all your
    rendering via the Graphics class instead.
*/
class JUCE_API  LowLevelGraphicsSoftwareRenderer    : public RenderingHelpers::StackBasedLowLevelGraphicsContext<RenderingHelpers::SoftwareRendererSavedState>
{
public:
    //==============================================================================
    /** Creates a context to render into an image. */
    LowLevelGraphicsSoftwareRenderer (const Image& imageToRenderOnto);

    /** Creates a context to render into a clipped subsection of an image. */
    LowLevelGraphicsSoftwareRenderer (const Image& imageToRenderOnto, Point<int> origin,
                                      const RectangleList<int>& initialClip);

    /** Destructor. */
    ~LowLevelGraphicsSoftwareRenderer();

private:
    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (LowLevelGraphicsSoftwareRenderer)
};


#endif   // JUCE_LOWLEVELGRAPHICSSOFTWARERENDERER_H_INCLUDED

 

Ignore codeblocks and whatever its right-click menu does. Like I said: look at the files on disk, and make sure that what's actually there is what you expect to be there.

In the Juce modules folder? It's there. In the project modules folder it's not.

Have you done something silly like pointed the introjucer's modules path to the modules folder that was created inside the project?

It runs now. I just put it all in there.

Thanks For the Support. ;)

No, not by default. I used the main modules folder.

Not that it's a crippling bug, but if you want to roll in and out of Juce it's kind of a hassle because the folder gets overwritten by Juce on each save. Still at least it works eh :)

Putting all your code in the project's internal modules folder is exactly the wrong thing to do!

Nobody else has ever mentioned having the problem you're talking about, I really can't think what might be different on your machine..

Referring to I should put a bare minimum in there? Or should it be linked only?  The thing is I was just repeating the process where I selected the main modules folder for my modules, making a new folder for my project and selecting my compiler in the radio group. But one thing I noticed was my Vstudio version of the Introjucer was of a better quality than the Codeblocks output. I had some warnings while compiling, and the logo was missing from the executable in Codeblocks. So, maybe it's my build? Tho it seems to be running fine with Glut and SDL..? Anyway it's probably beyond me what's happening.

Our policy for codeblocks/mingw is that we don't actively maintain it - if people want to use it, they do so at their own risk, and we rely on users giving us feedback + fixes if something stops working. Not many people use it, and most likely it needs a bit of attention.

On Windows we'd definitely recommend VS as a better dev environment, and we do constantly check and use that ourselves.

I see,

It's a bit of full circle,  but it's impossible for me to evaluate VS express. I had it, and shure it's great but I can't  run it offline. With the current state of events this shotty CodeBlocks scenario seems to work. Even tho it may be a thought experiment. Heard a lot of great things about QT, but havnt had the time to explore it.  The help I got so far is greatly appreciated.