Moving from Text Editor and CLI to an IDE

SDL Development
1

Righto, so I’ve run into an issue with trying to use a couple different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type and
references GraphicsEngine.h as the source. Also while messing with eclipse
I see that it first tries to compile GraphicsEngine.cpp I think. I started
it as a hello world C++ project and added that folder/class. I’m on Linux
Mint 15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to make
my life easier.

2

Righto, so I’ve run into an issue with trying to use a couple different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type and
references GraphicsEngine.h as the source. Also while messing with eclipse
I see that it first tries to compile GraphicsEngine.cpp I think. I started
it as a hello world C++ project and added that folder/class. I’m on Linux
Mint 15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to make
my life easier.

3

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

KaiOn Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown wrote:

Righto, so I’ve run into an issue with trying to use a couple different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type and
references GraphicsEngine.h as the source. Also while messing with eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I started it
as a hello world C++ project and added that folder/class. I’m on Linux Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently I’m using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

Did you add the appropriate compiler and linker flags so SDL can be found?
On the command line in Linux, you would compile with something like this
tacked on: sdl2-config --cflags and link with this appended: sdl2-config --libs or do both with sdl2-config --cflags --libs. IDEs are no
different, but you have to figure out where to put that stuff.
Code::Blocks has it under Project > Build options… > Compiler settings
tab > Other options tab and the Linker settings tab > Other linker options
field.

Jonny DOn Thu, Oct 31, 2013 at 12:02 PM, Kai Sterker <kai.sterker at gmail.com> wrote:

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

Kai

On Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown wrote:

Righto, so I’ve run into an issue with trying to use a couple different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type and
references GraphicsEngine.h as the source. Also while messing with
eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I started
it
as a hello world C++ project and added that folder/class. I’m on Linux
Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to
make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

5

I’ve done both #include <SDL2/SDL.h> with -lSDL2 and #include"SDL.h" with
sdl2-config --cflags --libs with both the IDE and CLI.

I tried renaming GraphicsEngine.cpp to .hpp and it will compile and run in
the IDE. I toyed around with other extensions and got three results.
Regular ones like cpp, cxx, and cc give the same error. Using hpp will make
treat it sort of like a header. When making the class with h as the header
and hpp as the source, it’ll generate an empty #include block in the hpp
file. If I try to implement an unimplemented method, it will generate it
inline in the header instead of the source like normal. I’m sure there’s a
plethora of other things that it messes up. If I make it generate with a
bogus extension like ccc, cx, or cplusplus, it will open an empty
GraphicsEngine.h in a text editor and not add anything to the project tree.
Strange.On Thu, Oct 31, 2013 at 12:58 PM, Jonathan Dearborn wrote:

Did you add the appropriate compiler and linker flags so SDL can be found?
On the command line in Linux, you would compile with something like this
tacked on: sdl2-config --cflags and link with this appended: sdl2-config --libs or do both with sdl2-config --cflags --libs. IDEs are no
different, but you have to figure out where to put that stuff.
Code::Blocks has it under Project > Build options… > Compiler settings
tab > Other options tab and the Linker settings tab > Other linker options
field.

Jonny D

On Thu, Oct 31, 2013 at 12:02 PM, Kai Sterker <kai.sterker at gmail.com>wrote:

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

Kai

On Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown <@Joshua_Brown> wrote:

Righto, so I’ve run into an issue with trying to use a couple different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type and
references GraphicsEngine.h as the source. Also while messing with
eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I
started it
as a hello world C++ project and added that folder/class. I’m on Linux
Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to
make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

Just remove the file if you are never using it.On Oct 31, 2013 2:20 PM, “Joshua Brown” wrote:

I’ve done both #include <SDL2/SDL.h> with -lSDL2 and #include"SDL.h" with
sdl2-config --cflags --libs with both the IDE and CLI.

I tried renaming GraphicsEngine.cpp to .hpp and it will compile and run in
the IDE. I toyed around with other extensions and got three results.
Regular ones like cpp, cxx, and cc give the same error. Using hpp will make
treat it sort of like a header. When making the class with h as the header
and hpp as the source, it’ll generate an empty #include block in the hpp
file. If I try to implement an unimplemented method, it will generate it
inline in the header instead of the source like normal. I’m sure there’s a
plethora of other things that it messes up. If I make it generate with a
bogus extension like ccc, cx, or cplusplus, it will open an empty
GraphicsEngine.h in a text editor and not add anything to the project tree.
Strange.

On Thu, Oct 31, 2013 at 12:58 PM, Jonathan Dearborn wrote:

Did you add the appropriate compiler and linker flags so SDL can be
found? On the command line in Linux, you would compile with something like
this tacked on: sdl2-config --cflags and link with this appended:
sdl2-config --libs or do both with sdl2-config --cflags --libs. IDEs
are no different, but you have to figure out where to put that stuff.
Code::Blocks has it under Project > Build options… > Compiler settings
tab > Other options tab and the Linker settings tab > Other linker options
field.

Jonny D

On Thu, Oct 31, 2013 at 12:02 PM, Kai Sterker <kai.sterker at gmail.com>wrote:

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

Kai

On Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown wrote:

Righto, so I’ve run into an issue with trying to use a couple different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type and
references GraphicsEngine.h as the source. Also while messing with
eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I
started it
as a hello world C++ project and added that folder/class. I’m on Linux
Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to
make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

I see. Kai already pointed it out. The IDE will run the compiler on all
of the “source” (.c, .cpp, .cxx, .cc) files you add to the project. You
should not #include GraphicsEngine.cpp if you have it added to the project.
#including “source” files (as opposed to “header” files: .h et al.) is
generally bad unless they’re C++ template implementation files.

So, either remove GraphicsEngine.cpp from the project’s file list or rename
it to a header extension that the IDE recognizes and knows not to compile
separately.

Jonny DOn Thu, Oct 31, 2013 at 2:28 PM, Andre D wrote:

Just remove the file if you are never using it.
On Oct 31, 2013 2:20 PM, “Joshua Brown” wrote:

I’ve done both #include <SDL2/SDL.h> with -lSDL2 and #include"SDL.h" with
sdl2-config --cflags --libs with both the IDE and CLI.

I tried renaming GraphicsEngine.cpp to .hpp and it will compile and run
in the IDE. I toyed around with other extensions and got three results.
Regular ones like cpp, cxx, and cc give the same error. Using hpp will make
treat it sort of like a header. When making the class with h as the header
and hpp as the source, it’ll generate an empty #include block in the hpp
file. If I try to implement an unimplemented method, it will generate it
inline in the header instead of the source like normal. I’m sure there’s a
plethora of other things that it messes up. If I make it generate with a
bogus extension like ccc, cx, or cplusplus, it will open an empty
GraphicsEngine.h in a text editor and not add anything to the project tree.
Strange.

On Thu, Oct 31, 2013 at 12:58 PM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

Did you add the appropriate compiler and linker flags so SDL can be
found? On the command line in Linux, you would compile with something like
this tacked on: sdl2-config --cflags and link with this appended:
sdl2-config --libs or do both with sdl2-config --cflags --libs. IDEs
are no different, but you have to figure out where to put that stuff.
Code::Blocks has it under Project > Build options… > Compiler settings
tab > Other options tab and the Linker settings tab > Other linker options
field.

Jonny D

On Thu, Oct 31, 2013 at 12:02 PM, Kai Sterker <kai.sterker at gmail.com>wrote:

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

Kai

On Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown wrote:

Righto, so I’ve run into an issue with trying to use a couple
different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and
runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type
and
references GraphicsEngine.h as the source. Also while messing with
eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I
started it
as a hello world C++ project and added that folder/class. I’m on
Linux Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to
make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

Okay, after letting it stew in my mind at work today, I figured it out. I’m
used to a handwritten Makefile that basically gives a couple options to
calling the compiler.

compile:
g++ 2dgame.cpp -o 2dgame
debug:
g++ -g 2dgame.cpp -o 2dgame -DGOGOGDB

Whereas an IDE generates an indecipherable mess. Well, that’s what it looks
like to me.

Anyways, moral of the story: With a simple call to g++, everything has to
be hierarchically included. My code would include SDL and MyClass.h.
MyClass.h would include its source. Etcetera. An IDE will compile each cpp
file as its own whatever, so each source file needs to include absolutely
everything it needs, including its header.

So, 2dgame.cpp includes SDL and GraphicsEngine.h . GraphicsEngine.cpp
includes SDL and GraphicsEngine.h . During the linking stage or something,
2dgame.cpp will make a call to a function declared in GraphicsEngine.h but
is implemented in GraphicsEngine.cpp . It knows to link the
GraphicsEngine.o (or whatever) even though nothing 2dgame.cpp or what it
included specifically includes GraphicsEngine.cpp . It’s automagical.

Which is basically what you were trying to tell me. Thanks!On Thu, Oct 31, 2013 at 2:32 PM, Jonathan Dearborn wrote:

I see. Kai already pointed it out. The IDE will run the compiler on all
of the “source” (.c, .cpp, .cxx, .cc) files you add to the project. You
should not #include GraphicsEngine.cpp if you have it added to the project.
#including “source” files (as opposed to “header” files: .h et al.) is
generally bad unless they’re C++ template implementation files.

So, either remove GraphicsEngine.cpp from the project’s file list or
rename it to a header extension that the IDE recognizes and knows not to
compile separately.

Jonny D

On Thu, Oct 31, 2013 at 2:28 PM, Andre D wrote:

Just remove the file if you are never using it.
On Oct 31, 2013 2:20 PM, “Joshua Brown” <@Joshua_Brown> wrote:

I’ve done both #include <SDL2/SDL.h> with -lSDL2 and #include"SDL.h"
with sdl2-config --cflags --libs with both the IDE and CLI.

I tried renaming GraphicsEngine.cpp to .hpp and it will compile and run
in the IDE. I toyed around with other extensions and got three results.
Regular ones like cpp, cxx, and cc give the same error. Using hpp will make
treat it sort of like a header. When making the class with h as the header
and hpp as the source, it’ll generate an empty #include block in the hpp
file. If I try to implement an unimplemented method, it will generate it
inline in the header instead of the source like normal. I’m sure there’s a
plethora of other things that it messes up. If I make it generate with a
bogus extension like ccc, cx, or cplusplus, it will open an empty
GraphicsEngine.h in a text editor and not add anything to the project tree.
Strange.

On Thu, Oct 31, 2013 at 12:58 PM, Jonathan Dearborn <grimfang4 at gmail.com wrote:

Did you add the appropriate compiler and linker flags so SDL can be
found? On the command line in Linux, you would compile with something like
this tacked on: sdl2-config --cflags and link with this appended:
sdl2-config --libs or do both with sdl2-config --cflags --libs. IDEs
are no different, but you have to figure out where to put that stuff.
Code::Blocks has it under Project > Build options… > Compiler settings
tab > Other options tab and the Linker settings tab > Other linker options
field.

Jonny D

On Thu, Oct 31, 2013 at 12:02 PM, Kai Sterker <kai.sterker at gmail.com>wrote:

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

Kai

On Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown <@Joshua_Brown> wrote:

Righto, so I’ve run into an issue with trying to use a couple
different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and
runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type
and
references GraphicsEngine.h as the source. Also while messing with
eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I
started it
as a hello world C++ project and added that folder/class. I’m on
Linux Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently I’m
using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try to
make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

9

Yep, that’s what the linker’s job is. It puts object (.o) files together
(which represent separate compilation units) so they can call functions
from each other to make a complete executable. The headers are strictly
for the compiler to know which functions are available to call.

Jonny DOn Thu, Oct 31, 2013 at 11:58 PM, Joshua Brown wrote:

Okay, after letting it stew in my mind at work today, I figured it out.
I’m used to a handwritten Makefile that basically gives a couple options to
calling the compiler.

compile:
g++ 2dgame.cpp -o 2dgame
debug:
g++ -g 2dgame.cpp -o 2dgame -DGOGOGDB

Whereas an IDE generates an indecipherable mess. Well, that’s what it
looks like to me.

Anyways, moral of the story: With a simple call to g++, everything has to
be hierarchically included. My code would include SDL and MyClass.h.
MyClass.h would include its source. Etcetera. An IDE will compile each cpp
file as its own whatever, so each source file needs to include absolutely
everything it needs, including its header.

So, 2dgame.cpp includes SDL and GraphicsEngine.h . GraphicsEngine.cpp
includes SDL and GraphicsEngine.h . During the linking stage or something,
2dgame.cpp will make a call to a function declared in GraphicsEngine.h but
is implemented in GraphicsEngine.cpp . It knows to link the
GraphicsEngine.o (or whatever) even though nothing 2dgame.cpp or what it
included specifically includes GraphicsEngine.cpp . It’s automagical.

Which is basically what you were trying to tell me. Thanks!

On Thu, Oct 31, 2013 at 2:32 PM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

I see. Kai already pointed it out. The IDE will run the compiler on all
of the “source” (.c, .cpp, .cxx, .cc) files you add to the project. You
should not #include GraphicsEngine.cpp if you have it added to the project.
#including “source” files (as opposed to “header” files: .h et al.) is
generally bad unless they’re C++ template implementation files.

So, either remove GraphicsEngine.cpp from the project’s file list or
rename it to a header extension that the IDE recognizes and knows not to
compile separately.

Jonny D

On Thu, Oct 31, 2013 at 2:28 PM, Andre D wrote:

Just remove the file if you are never using it.
On Oct 31, 2013 2:20 PM, “Joshua Brown” wrote:

I’ve done both #include <SDL2/SDL.h> with -lSDL2 and #include"SDL.h"
with sdl2-config --cflags --libs with both the IDE and CLI.

I tried renaming GraphicsEngine.cpp to .hpp and it will compile and run
in the IDE. I toyed around with other extensions and got three results.
Regular ones like cpp, cxx, and cc give the same error. Using hpp will make
treat it sort of like a header. When making the class with h as the header
and hpp as the source, it’ll generate an empty #include block in the hpp
file. If I try to implement an unimplemented method, it will generate it
inline in the header instead of the source like normal. I’m sure there’s a
plethora of other things that it messes up. If I make it generate with a
bogus extension like ccc, cx, or cplusplus, it will open an empty
GraphicsEngine.h in a text editor and not add anything to the project tree.
Strange.

On Thu, Oct 31, 2013 at 12:58 PM, Jonathan Dearborn < @Jonathan_Dearborn> wrote:

Did you add the appropriate compiler and linker flags so SDL can be
found? On the command line in Linux, you would compile with something like
this tacked on: sdl2-config --cflags and link with this appended:
sdl2-config --libs or do both with sdl2-config --cflags --libs. IDEs
are no different, but you have to figure out where to put that stuff.
Code::Blocks has it under Project > Build options… > Compiler settings
tab > Other options tab and the Linker settings tab > Other linker options
field.

Jonny D

On Thu, Oct 31, 2013 at 12:02 PM, Kai Sterker <kai.sterker at gmail.com>wrote:

Despite the fact that this problem has nothing to do with SDL
whatsoever, I would imagine that you’ve added your GraphicsEngine.cpp
file to the IDE project. The IDE tries to compile that and fails for
obvious reasons. The same would happen if you’d run

“g++ -c GraphicsEngine.cpp”

In general, it’s good practice to not include source (.cpp) files from
other source files. Only ever include header (.h) files. Each .cpp
file must be able to be compiled individually.

Regards,

Kai

On Thu, Oct 31, 2013 at 4:34 PM, Joshua Brown wrote:

Righto, so I’ve run into an issue with trying to use a couple
different
IDE’s. Specifically Code::Blocks and Eclipse with CDT (C Dev Tools).

I’ve got three source files.

2dgame.cpp
/*************************************************/
#include
#include <SDL2/SDL.h>
using namespace std;

#include “GraphicsEngine/GraphicsEngine.cpp”

SDL_Renderer* butitworkshere;

int main() {
cout << “whoopee” << endl;
return 0;
}
/*************************************************/

GraphicsEngine.cpp
//
#include"GraphicsEngine.h"
//

GraphicsEngine.h
//
class GraphicsEngine {
private:
SDL_Renderer renderer;
public:
GraphicsEngine();
};
/*/

Compiles just fine with a good old “g++ 2dgame.cpp -o 2dgame” and
runs.
Both Code::Blocks and Eclipse say SDL_Renderer does not name a type
and
references GraphicsEngine.h as the source. Also while messing with
eclipse I
see that it first tries to compile GraphicsEngine.cpp I think. I
started it
as a hello world C++ project and added that folder/class. I’m on
Linux Mint
15 64-bit. I’ve tried Eclipse from the repos first but currently
I’m using
the package downloaded from eclipse.org .

I’m frustrated because I came to IDE’s yesterday and today to try
to make my
life easier.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

10

I’m frustrated because I came to IDE’s yesterday and today to try to make my
life easier.

Now you see: they don’t.

Code::Blocks is so bad at the build process that I can’t even find a
suitable word for that, and Eclipse/CDT cannot get it right until you
handwalk it to generate the makefiles needed (a bit less frustrating
in CMake case). Which is guaranteed to eat more time and brains than
to set up a decent build farm based on any other build tool. Yes, even
auto{conf|make}.

That is not to mention how even Eclipse+CDT is bad at what IDEs are
supposed to be good at. The only thing it helps is with class
browsing… But when you find yourself in need of it - you know you are
in deep shit patching worst case of codepasting nightmare possible.
God help you.

Stay away from IDEs as long as possible, and try to refactor if it
isn’t (possible, that is).–

./lxnt

11

What? This is terrible advice.

IDE’s most certainly have their place; I strongly recommend you use app
code. It’s an amazing piece of software.
(http://www.jetbrains.com/objc/ <— Don’t be fooled, it supports
objective-C, C++ and C, not just objective c)~
Doug.

On Mon, Nov 4, 2013 at 5:37 AM, Alexander Sabourenkov wrote:

I’m frustrated because I came to IDE’s yesterday and today to try to
make my
life easier.

Now you see: they don’t.

Code::Blocks is so bad at the build process that I can’t even find a
suitable word for that, and Eclipse/CDT cannot get it right until you
handwalk it to generate the makefiles needed (a bit less frustrating
in CMake case). Which is guaranteed to eat more time and brains than
to set up a decent build farm based on any other build tool. Yes, even
auto{conf|make}.

That is not to mention how even Eclipse+CDT is bad at what IDEs are
supposed to be good at. The only thing it helps is with class
browsing… But when you find yourself in need of it - you know you are
in deep shit patching worst case of codepasting nightmare possible.
God help you.

Stay away from IDEs as long as possible, and try to refactor if it
isn’t (possible, that is).

–

./lxnt

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

12

Well, well.

I didn’t consider the ObjC and the whole Apple ecosystem in my reply,
partially because the original question never mentioned it, and the
other part being I never even seriously contemplated learning anything
about it. Please don’t deny that your reply is focused on ios/osx,
while the question had nothing to do with it.

Pray tell, why is it that while I don’t need anything above a good
code editor and a decent build system, I would suddenly need a
gigabytes-ram-eating, slow-as-hell, idiotic-rule-enforcing (because
design trumps your needs), buggy as hell (because nothing of a size of
an IDE can be reasonably bug-free), build-system-choice limiting piece
of code (heh) while my requirement is to have a 100% reliable, and,
most importantly, stable and easily integrated with the tests or, even
more importantly, the continuous integration, release and publishing
process.

In my opinion, the only useful thing in IDEs are various iterations
upon class-browsers. I view them mostly as concessions to horrible
coding practices present - C++ and Java come to mind - where those
browsers really speed up acquiring familiriaty with the code. Which is
only needed because the code in question has rotten beyond any
reasonable hope of refactoring.

IDEs can only be useful when trying to make heads or tails of an
abandoned pile of code in a not-quite-familiar language. Even at that,
only the class/type browsers are of any use.

IDEs can not help in writing new code - every gimmick they offer only
delays the inevitable learning of how exactly the system you’re coding
to works, and steal your time at that.On Mon, Nov 4, 2013 at 12:11 PM, Doug <douglas.linder at gmail.com> wrote:

What? This is terrible advice.

IDE’s most certainly have their place; I strongly recommend you use app
code. It’s an amazing piece of software.
(http://www.jetbrains.com/objc/ <— Don’t be fooled, it supports
objective-C, C++ and C, not just objective c)

13

Let’s keep the hyperbole off this list please. There’s no value in a
discussion full of logical fallacies. Some people like IDEs while
other’s don’t. Leave it at that, because this conversation is going no
where.On 11/04/2013 04:23 PM, Alexander Sabourenkov wrote:

On Mon, Nov 4, 2013 at 12:11 PM, Doug <douglas.linder at gmail.com> wrote:

What? This is terrible advice.

IDE’s most certainly have their place; I strongly recommend you use app
code. It’s an amazing piece of software.
(http://www.jetbrains.com/objc/ <— Don’t be fooled, it supports
objective-C, C++ and C, not just objective c)
Well, well.

I didn’t consider the ObjC and the whole Apple ecosystem in my reply,
partially because the original question never mentioned it, and the
other part being I never even seriously contemplated learning anything
about it. Please don’t deny that your reply is focused on ios/osx,
while the question had nothing to do with it.

Pray tell, why is it that while I don’t need anything above a good
code editor and a decent build system, I would suddenly need a
gigabytes-ram-eating, slow-as-hell, idiotic-rule-enforcing (because
design trumps your needs), buggy as hell (because nothing of a size of
an IDE can be reasonably bug-free), build-system-choice limiting piece
of code (heh) while my requirement is to have a 100% reliable, and,
most importantly, stable and easily integrated with the tests or, even
more importantly, the continuous integration, release and publishing
process.

In my opinion, the only useful thing in IDEs are various iterations
upon class-browsers. I view them mostly as concessions to horrible
coding practices present - C++ and Java come to mind - where those
browsers really speed up acquiring familiriaty with the code. Which is
only needed because the code in question has rotten beyond any
reasonable hope of refactoring.

IDEs can only be useful when trying to make heads or tails of an
abandoned pile of code in a not-quite-familiar language. Even at that,
only the class/type browsers are of any use.

IDEs can not help in writing new code - every gimmick they offer only
delays the inevitable learning of how exactly the system you’re coding
to works, and steal your time at that.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org