I'm a learner; and running Dev-C++ 4.9.9.2 on Win' XP-Pro,
coding in "C".
This is my first try at getting something printed
on the console.I've searched this forum, and found
one "SDL Hello World" post, but it deals with: "no such
file or directory" problem, which is not my case.
The program compiles without errors; when run opens
a blank console window.
Could you help me to get this program running?
Please recommend a good book, or tutorial also.
Thank you,
Pellum.
include <stdio.h>
include <stdlib.h>
include <SDL/SDL.h>
int main(int argc, char argv[]) /Compiles without errors, opens a blank window./
{
SDL_Init(SDL_INIT_VIDEO);
{
printf("\nHello World!\n");
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 ) / initialize SDL */
{
fprintf( stderr, "Video initialization failed: %s\n",
SDL_GetError( ));
Yeah it would seem as though Capture Output has something
to do with it, but not in the way we expected. It turns out
that it needs to be off for the prog to open a console
window. I showed you the EditPlus compiler options, when really
I should've shown the "Run" options:
If I turn on "Capture Output", then only the graphics window
opens, and nothing else.
So now it seems Editplus can do two pieces of magic; turning off
the 'fake console window' which we can't print to, and
turning on the proper console window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If this is your first attempt at printing to a console, and you are learning C, why are you using SDL?
What is actually happening her is a little funky. The SDL header redefines main with a #define macro, so that this is in fact a call to SDL_main() (I discovered this the hard way by trying to debug your code), the real main() entry point (in fact WinMain) is provided by the SDL framework. So what looks like console mode code is in fact GUI code.
An SDL app is built as a GUI app and therefore has no console window in which printf output will appear. The reason you get a console window at all is because the system() call invokes cmd.exe (you will notice that that is the name in the window title, not your application).
I really cannot fathom why you are using SDL in any case. Start this way: File->New->Project->Introduction->Hello World.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too am looking to output text to the console when using SDL.
I really need to know to do this, after hunting around
the forum, and trying out many things myself.
I know it should be possible; after all, when I use
a text editor, and link in SDL etc., I can use the following
lines so that all text is redirected to the command line:
When you set Dev-C++ to create a GUI application (which is what the SDL DevPak project template does), it suppresses the console window. The Window you are presented with is a graphics window not a console. It may look very similar however is you don't draw anything on it!
The simple solution is to set the project to a Console app. You will then get both the graphics window and the console window. You do not need freopen() to redirect the I/O to this, it is the default.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Basically, I link in -lmingw32 -lSDLmain -lSDL -mwindows.
No you did not. -mwindows does not link a library it suppresses the console window.
Even if you select a console app, if you add that option you will not get a console. This option may be added manually or it is set by setting the "Do not create a console window" to "Yes" in the project compiler options. (Don't ask me why the author did not think that was not a confusingly named option, or why he used "yes/no" drop downs rather than a tick boxes.)
>> When I run the program, a console window is opened,[...]
No it is not. I tested it. I explained that in the first response! The console window that opens is opened by the system() call, it is not the stdout console for your program. To prove that (if needed, since the window title already does that), add Sleep(10000) before the system call (you will need to include <windows.h>), and you will see that the console window will not appear until ten seconds have expired.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> No you did not. -mwindows does not link a
>> library it suppresses the console window.
Yes I did. I'm not sure what's going on, but I definitely have -mwindows in there.
Just to be sure, the console window we're talking about is labelled "cmd.exe", and it opens, and says "Press any key to continue".
Just to be doubly sure, in the "Additional command-line options" tab of "Project Options", I enter "-lmingw32 -lSDLmain -lSDL -mwindows" into the "Linker" section.
Yes, I tested it ;P
The only thing I can think of is that I am using a variant of Dev-C++ - wxDev-c++ (which is specially tailored for wxWidgets). It shouldn't make a difference, but perhaps it does.
>> The console window that opens is opened by the system() call,
>> it is not the stdout console for your program.
This "console window that is opened by the system() call"; does it look identical to a standard console window with ".....\cmd.exe" at the draggable frame top?
In any case, I tried without -mwindows, and it does the same - still opens, but I can't write to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Yes I did. I'm not sure what's going on, but
>> I definitely have -mwindows in there.
Stop! Think! I am saying that you should not "have -mwindows in there". What don't you understand about "it suppresses the console"!? If you want a console, that is precisely what you don't want to do.
>> Just to be doubly sure, in the "Additional command-line options"
>> tab of "Project Options", I enter "-lmingw32 -lSDLmain -lSDL
>> -mwindows" into the "Linker" section.
Just to be doubly sure remove -mwindows.
>> does it look identical to a standard console
>> window with ".....\cmd.exe" at the draggable
>> frame top?
Yes! I said that twice. The first time in the very first response.
>> In any case, I tried without -mwindows, and it does the same
>> still opens, but I can't write to it.
Post the entire build log from a "build-all". When I tried it, the SDL window opened, but the console did not, but the "pause" command was still executed (I know because I ran it in the Insight debugger), but with no window to enter a response. I had to manually terminate (via Task Manager) the cmd.exe process that it created. Your mileage may vary.
Because SDL 'fakes' the main() entry point by defining it as a macro the framework executes before your main() is called. Perhaps that processing includes closing stdio and the console window. I could take a closer look at the framework to determine if there is a fix, but frankly I do not see the worth of it.
Perhaps this is just too hard if the framework is standing in your way, I would ask what, in a graphics application, you want to use stdout for? If it is for debugging then I would suggest an alternative approach. The trick of enabling the console window in a GUI app is something I have only ever managed to achieve using GCC so it is not a very portable technique.
One simple approach is to stream the text via TCP/IP and have a client process display it. This has the advantage of being able to have the debug output on a remote machine, or to have multiple processes display in one client. Of course you may also simply use a debugger. I don't know about wxDev-C++ but in Dev-C++ the debugger plain sucks. I use Insight instead. Even then it is not a patch on VC++ 2008 Express Edition.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Yes I did. I'm not sure what's going on, but
>> I definitely have -mwindows in there.
> Stop! Think! I am saying that you should not
> have -mwindows in there". What don't you
> understand about "it suppresses the console"!?
> If you want a console, that is precisely what you
> don't want to do.
I knew you were saying that. I was only replying
"Yes I did" to your "No you did not" comment.
If you would have said "No you do/should not",
then I think the confusion wouldn't have arised.
Was it a typo?
Yes, I was slightly confused that you went on to
say the rest, but failing to use occam's razor
100%, I thought that you might have thought that
that I was a complete newbie and confusing
the graphics window with the console window.
Therefore I interpreted your "No you did not" as
"You couldn't have, otherwise the console window
you saw wouldn't have opened" (me still thinking
that you thought I may have confused the graphics
window with the console window). Hope that clears
things up.
Anyway, putting that aside, you're right - I want
it for debugging, but also so that I can close the
program more easily (when you close the graphics
window instead, it crashes unfortunately).
Also bear in mind that using a text editor, and
compiling manually, that I can get the console
printed to then.
> Post the entire build log from a "build-all"
Where can I find the build log?
I will have to look into TCP/IP and debugger stuff.
The TCP/IP option sounds tempting in particular if
you have a link to a web page I can study.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No. The effect of selecting GUI or console is exactly to add or remove the -mwindows option. There was no way of knowing that you had added it manually.
> when you close the graphics window
> instead, it crashes unfortunately
Perhaps you need to fix that bug first, since I am sure many people use SDL without any problem.
> Also bear in mind that using a text editor, and
> compiling manually, that I can get the console
> printed to then.
Ah! That's interesting. Then you should perhaps compare the steps you take to build manually with those executed by Dev-C++. These are shown in their entirety in the Compile Log, which is why you are generally asked to post that. In this case you might post the manual steps as well - the differences will be telling I think. In the end all Dev-C++ does is generate a make file to launch the compiler and linker, there is no magic going on, so comparing the automated build with the manual one, we should be able to get the managed build to behave like the manual one.
> Where can I find the build log?
After a build, the Compile Log tab at the bottom of the Dev-C++ window shows execution of all the build steps, the text can be copy & pasted. If you have never looked at it before, you may find that now you know that it is there you can solve your own problem.
> I will have to look into TCP/IP and debugger stuff.
I really wish that everyone that ever teaches, writes a book, or posted a web-tutorial on programming included the use of a debugger as the second lesson - right after "hello, world". It would save so much time, pain, and frustration. I first encountered symbolic debuggers in 1989 with Microsoft's CodeView debugger. At the time, CodeView was the most compelling reason to buy Microsoft's compiler. Trust me, learning to use it will be the most productive half hour in your programming career. However don't expect Dev-C++'s built in debug tools to work, let alone impress, even the 20 year old CodeView looks sophisticated in comparison. A build of Insight that works with Dev-C++ can be obtained from teh MinGW download site at http://sourceforge.net/project/showfiles.php?group_id=2435 . It can be integrated reasonably well via the "Tools|Configure Tools..." menu. It has macros that allow you to pass the program executable to the debugger (but not unfortunately project command line parameters).
If you really want the Rolls-Royce of debuggers, use VC++ 2008 Express Edition, also free, and if you are not using wxWidgets, you don't really loose anything that wxDev-C++ gives, and you get much more besides. If you really like wxDev-C++, unlike plain Dev-C++ it can use VC++ as an alternative toolchain.
Clifford
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the delay, let's have another look at this...
> No. The effect of selecting GUI or console is
> exactly to add or remove the -mwindows option.
> There was no way of knowing that you had added
> it manually.
It's all a bit vague in my memory now, but I did
initially say that 'I enter[ed] "-lmingw32 -lSDLmain
-lSDL -mwindows" into the "Linker" section.' in the
'"Additional command-line options" tab of "Project
Options"' in my 2008-04-05 17:12 post, which implied
manually doing it.
> In this case you might post the manual steps as
> well - the differences will be telling I think.
Okay this is where things get weird. I use the following:
make.exe -f makefile MAINFILE=prog.cpp OUTFILE=a -s
I could give you the contents of the makefile too.
However, before I do, I should say that if any magic is
happening, then it's with my text editor - EditPlus. I
tried compiling manually with the command prompt, using
exactly the same makefile and argument above "make.exe -f
makefile" etc., and while EditPlus gives us what we want,
doing it through the command line acts just how DevC++ did.
Whether that helps narrow down the solution, or just confuse
things further, I have no idea.
For your reference, the Dev-C++ log is here, though I doubt it'll
help:
Compiler: Default GCC compiler
Building Makefile: "C:\Main\New Folder (3)\Makefile.win"
Executing make...
mingw32-make.exe -f "C:\Main\New Folder (3)\Makefile.win" all
mingw32-make.exe: Nothing to be done for `all'.
Execution terminated
Compilation successful
On your advice, I think I might try VC++ 2008 Express Edition
and get into its debugger. I've found that Dev-C++ has some
multiple undo problems which I've found annoying lately.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure how a text editor can do 'magic'. That is indeed a strange observation. I wonder what "Capture output" might be doing? Forcing the opening of a console window that the SDL framework otherwise closes perhaps?
The Dev-C++ log shows nothing useful because the build was up-to-date. You need to post the log from a Rebuild-all to force a rebuild and show all the useful information. However I think it no longer helps. I have reproduced your problem, and I too cannot get an SDL application to create a console window, so I think that the SDL framework is somehow killing it at runtime.
Because SDL redefines 'main; as a macro, debugging the framework start-up to see how it might be doing that would require rebuilding the SDL code for debug. It is possible I believe to programatically open a console window and redirect stdout to it (which is what I am guessing EditPlus is doing).
The ouptut of the make was what I really wanted to show the 'steps', the make command line alone is not very helpful. You can copy & paste text from a console window you know. However like the Dev-C++ log, I think it may no longer be useful.
Note that using spaces in project and source file paths is a bad idea. Dev-C++ and GNU make do not always cork correctly when faced with spaces in file names and paths.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm a learner; and running Dev-C++ 4.9.9.2 on Win' XP-Pro,
coding in "C".
This is my first try at getting something printed
on the console.I've searched this forum, and found
one "SDL Hello World" post, but it deals with: "no such
file or directory" problem, which is not my case.
The program compiles without errors; when run opens
a blank console window.
Could you help me to get this program running?
Please recommend a good book, or tutorial also.
Thank you,
Pellum.
include <stdio.h>
include <stdlib.h>
include <SDL/SDL.h>
int main(int argc, char argv[]) /Compiles without errors, opens a blank window./
{
SDL_Init(SDL_INIT_VIDEO);
{
printf("\nHello World!\n");
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 ) / initialize SDL */
{
fprintf( stderr, "Video initialization failed: %s\n",
SDL_GetError( ));
}
/***************/
Yeah it would seem as though Capture Output has something
to do with it, but not in the way we expected. It turns out
that it needs to be off for the prog to open a console
window. I showed you the EditPlus compiler options, when really
I should've shown the "Run" options:
http://www.skytopia.com/stuff/EPcompile.jpg
If I turn on "Capture Output", then only the graphics window
opens, and nothing else.
So now it seems Editplus can do two pieces of magic; turning off
the 'fake console window' which we can't print to, and
turning on the proper console window.
If this is your first attempt at printing to a console, and you are learning C, why are you using SDL?
What is actually happening her is a little funky. The SDL header redefines main with a #define macro, so that this is in fact a call to SDL_main() (I discovered this the hard way by trying to debug your code), the real main() entry point (in fact WinMain) is provided by the SDL framework. So what looks like console mode code is in fact GUI code.
An SDL app is built as a GUI app and therefore has no console window in which printf output will appear. The reason you get a console window at all is because the system() call invokes cmd.exe (you will notice that that is the name in the window title, not your application).
I really cannot fathom why you are using SDL in any case. Start this way: File->New->Project->Introduction->Hello World.
Clifford
yeah in order to output text via SDL you need to get the TTF (truetypefont) lib.
what you would do is blit your text to an SDL_Surface backbuffer, and SDL_Flip (surface) ;
The TTF lib has a reference and help manual i think but its not hard once your used to using SDL.
btw...
if your setting up an SDL project you'd select multimedia application->SDL....
not a console application.
Repling to an oldish post about this SDL IO with characters.
If OP is still having trouble with IO text in SDL.
This will print a number to screen......
code/
header : std::string nout (int) ;
std::string nout ( int num )
{
std::stringstream ss;
ss<<num;
return ss.str();
}
e.g. nout (5) ;
endcode/
more importantly to get strings on screen...
code/
header : talk (int, int, int, SDL_Surface, TTF_Font, std::string) ;
void talk ( int colour, int x, int y, SDL_Surface text,
SDL_Surface screen, TTF_Font* font, std::string message )
{
// define your own color values first... //eg... #define colour1 100, 100, 100, 255 (R-G-B-alpha) if ( colour == 1 ){text=TTF_RenderText_Solid(font,message.c_str(),color1);} else if ( colour == 2 ){text=TTF_RenderText_Solid(font,message.c_str(),color2);} else if ( colour == 3 ){text=TTF_RenderText_Solid(font, message.c_str(),color3);} else if ( colour == 4 ){text=TTF_RenderText_Solid(font, message.c_str(),color4);} apply_surface( x, y, text, screen ); SDL_FreeSurface( text );}
eg....
talk (1, 0, 0, textSurface, screenSurface, font, msgString) ;
this should work.
I only said 'should' cause you never know.
Hope it helps someone like me.
I too am looking to output text to the console when using SDL.
I really need to know to do this, after hunting around
the forum, and trying out many things myself.
I know it should be possible; after all, when I use
a text editor, and link in SDL etc., I can use the following
lines so that all text is redirected to the command line:
freopen( "CON", "w", stdout );
freopen( "CON", "w", stderr );
However, this does not work with Dev-C++. What is one
supposed to do?
When you set Dev-C++ to create a GUI application (which is what the SDL DevPak project template does), it suppresses the console window. The Window you are presented with is a graphics window not a console. It may look very similar however is you don't draw anything on it!
The simple solution is to set the project to a Console app. You will then get both the graphics window and the console window. You do not need freopen() to redirect the I/O to this, it is the default.
Clifford
Thanks for your response.
I did set the project to console app.
Basically, I link in -lmingw32 -lSDLmain -lSDL -mwindows.
I also include in the c file:
include <SDL/SDL.h>
When I run the program, a console window is opened, but no text can be written to it.
>> Basically, I link in -lmingw32 -lSDLmain -lSDL -mwindows.
No you did not. -mwindows does not link a library it suppresses the console window.
Even if you select a console app, if you add that option you will not get a console. This option may be added manually or it is set by setting the "Do not create a console window" to "Yes" in the project compiler options. (Don't ask me why the author did not think that was not a confusingly named option, or why he used "yes/no" drop downs rather than a tick boxes.)
>> When I run the program, a console window is opened,[...]
No it is not. I tested it. I explained that in the first response! The console window that opens is opened by the system() call, it is not the stdout console for your program. To prove that (if needed, since the window title already does that), add Sleep(10000) before the system call (you will need to include <windows.h>), and you will see that the console window will not appear until ten seconds have expired.
Clifford
>> No you did not. -mwindows does not link a
>> library it suppresses the console window.
Yes I did. I'm not sure what's going on, but I definitely have -mwindows in there.
Just to be sure, the console window we're talking about is labelled "cmd.exe", and it opens, and says "Press any key to continue".
Just to be doubly sure, in the "Additional command-line options" tab of "Project Options", I enter "-lmingw32 -lSDLmain -lSDL -mwindows" into the "Linker" section.
Yes, I tested it ;P
The only thing I can think of is that I am using a variant of Dev-C++ - wxDev-c++ (which is specially tailored for wxWidgets). It shouldn't make a difference, but perhaps it does.
>> The console window that opens is opened by the system() call,
>> it is not the stdout console for your program.
This "console window that is opened by the system() call"; does it look identical to a standard console window with ".....\cmd.exe" at the draggable frame top?
In any case, I tried without -mwindows, and it does the same - still opens, but I can't write to it.
By the way, the "Press any key to continue" text is thanks to using system("PAUSE");
>> Yes I did. I'm not sure what's going on, but
>> I definitely have -mwindows in there.
Stop! Think! I am saying that you should not "have -mwindows in there". What don't you understand about "it suppresses the console"!? If you want a console, that is precisely what you don't want to do.
>> Just to be doubly sure, in the "Additional command-line options"
>> tab of "Project Options", I enter "-lmingw32 -lSDLmain -lSDL
>> -mwindows" into the "Linker" section.
Just to be doubly sure remove -mwindows.
>> does it look identical to a standard console
>> window with ".....\cmd.exe" at the draggable
>> frame top?
Yes! I said that twice. The first time in the very first response.
>> In any case, I tried without -mwindows, and it does the same
>> still opens, but I can't write to it.
Post the entire build log from a "build-all". When I tried it, the SDL window opened, but the console did not, but the "pause" command was still executed (I know because I ran it in the Insight debugger), but with no window to enter a response. I had to manually terminate (via Task Manager) the cmd.exe process that it created. Your mileage may vary.
Because SDL 'fakes' the main() entry point by defining it as a macro the framework executes before your main() is called. Perhaps that processing includes closing stdio and the console window. I could take a closer look at the framework to determine if there is a fix, but frankly I do not see the worth of it.
Perhaps this is just too hard if the framework is standing in your way, I would ask what, in a graphics application, you want to use stdout for? If it is for debugging then I would suggest an alternative approach. The trick of enabling the console window in a GUI app is something I have only ever managed to achieve using GCC so it is not a very portable technique.
One simple approach is to stream the text via TCP/IP and have a client process display it. This has the advantage of being able to have the debug output on a remote machine, or to have multiple processes display in one client. Of course you may also simply use a debugger. I don't know about wxDev-C++ but in Dev-C++ the debugger plain sucks. I use Insight instead. Even then it is not a patch on VC++ 2008 Express Edition.
Clifford
> Just to be doubly sure remove -mwindows.
Right, gone for good.
>> Yes I did. I'm not sure what's going on, but
>> I definitely have -mwindows in there.
> Stop! Think! I am saying that you should not
> have -mwindows in there". What don't you
> understand about "it suppresses the console"!?
> If you want a console, that is precisely what you
> don't want to do.
I knew you were saying that. I was only replying
"Yes I did" to your "No you did not" comment.
If you would have said "No you do/should not",
then I think the confusion wouldn't have arised.
Was it a typo?
Yes, I was slightly confused that you went on to
say the rest, but failing to use occam's razor
100%, I thought that you might have thought that
that I was a complete newbie and confusing
the graphics window with the console window.
Therefore I interpreted your "No you did not" as
"You couldn't have, otherwise the console window
you saw wouldn't have opened" (me still thinking
that you thought I may have confused the graphics
window with the console window). Hope that clears
things up.
Anyway, putting that aside, you're right - I want
it for debugging, but also so that I can close the
program more easily (when you close the graphics
window instead, it crashes unfortunately).
Also bear in mind that using a text editor, and
compiling manually, that I can get the console
printed to then.
> Post the entire build log from a "build-all"
Where can I find the build log?
I will have to look into TCP/IP and debugger stuff.
The TCP/IP option sounds tempting in particular if
you have a link to a web page I can study.
> Was it a typo?
No. The effect of selecting GUI or console is exactly to add or remove the -mwindows option. There was no way of knowing that you had added it manually.
> when you close the graphics window
> instead, it crashes unfortunately
Perhaps you need to fix that bug first, since I am sure many people use SDL without any problem.
> Also bear in mind that using a text editor, and
> compiling manually, that I can get the console
> printed to then.
Ah! That's interesting. Then you should perhaps compare the steps you take to build manually with those executed by Dev-C++. These are shown in their entirety in the Compile Log, which is why you are generally asked to post that. In this case you might post the manual steps as well - the differences will be telling I think. In the end all Dev-C++ does is generate a make file to launch the compiler and linker, there is no magic going on, so comparing the automated build with the manual one, we should be able to get the managed build to behave like the manual one.
> Where can I find the build log?
After a build, the Compile Log tab at the bottom of the Dev-C++ window shows execution of all the build steps, the text can be copy & pasted. If you have never looked at it before, you may find that now you know that it is there you can solve your own problem.
> I will have to look into TCP/IP and debugger stuff.
I really wish that everyone that ever teaches, writes a book, or posted a web-tutorial on programming included the use of a debugger as the second lesson - right after "hello, world". It would save so much time, pain, and frustration. I first encountered symbolic debuggers in 1989 with Microsoft's CodeView debugger. At the time, CodeView was the most compelling reason to buy Microsoft's compiler. Trust me, learning to use it will be the most productive half hour in your programming career. However don't expect Dev-C++'s built in debug tools to work, let alone impress, even the 20 year old CodeView looks sophisticated in comparison. A build of Insight that works with Dev-C++ can be obtained from teh MinGW download site at http://sourceforge.net/project/showfiles.php?group_id=2435 . It can be integrated reasonably well via the "Tools|Configure Tools..." menu. It has macros that allow you to pass the program executable to the debugger (but not unfortunately project command line parameters).
If you really want the Rolls-Royce of debuggers, use VC++ 2008 Express Edition, also free, and if you are not using wxWidgets, you don't really loose anything that wxDev-C++ gives, and you get much more besides. If you really like wxDev-C++, unlike plain Dev-C++ it can use VC++ as an alternative toolchain.
Clifford
Clifford
Sorry for the delay, let's have another look at this...
> No. The effect of selecting GUI or console is
> exactly to add or remove the -mwindows option.
> There was no way of knowing that you had added
> it manually.
It's all a bit vague in my memory now, but I did
initially say that 'I enter[ed] "-lmingw32 -lSDLmain
-lSDL -mwindows" into the "Linker" section.' in the
'"Additional command-line options" tab of "Project
Options"' in my 2008-04-05 17:12 post, which implied
manually doing it.
> In this case you might post the manual steps as
> well - the differences will be telling I think.
Okay this is where things get weird. I use the following:
make.exe -f makefile MAINFILE=prog.cpp OUTFILE=a -s
I could give you the contents of the makefile too.
However, before I do, I should say that if any magic is
happening, then it's with my text editor - EditPlus. I
tried compiling manually with the command prompt, using
exactly the same makefile and argument above "make.exe -f
makefile" etc., and while EditPlus gives us what we want,
doing it through the command line acts just how DevC++ did.
Whether that helps narrow down the solution, or just confuse
things further, I have no idea.
I have uploaded a picture of the Editplus options you may
want to see:
http://www.skytopia.com/stuff/EPcompile.jpg
For your reference, the Dev-C++ log is here, though I doubt it'll
help:
Compiler: Default GCC compiler
Building Makefile: "C:\Main\New Folder (3)\Makefile.win"
Executing make...
mingw32-make.exe -f "C:\Main\New Folder (3)\Makefile.win" all
mingw32-make.exe: Nothing to be done for `all'.
Execution terminated
Compilation successful
On your advice, I think I might try VC++ 2008 Express Edition
and get into its debugger. I've found that Dev-C++ has some
multiple undo problems which I've found annoying lately.
In my last post, instead of saying:
"using exactly the same makefile and argument
above "make.exe -f makefile" etc.""
...I meant to put:
"using exactly the same makefile and argument
above (i.e. "make.exe -f makefile" etc.")."
I am not sure how a text editor can do 'magic'. That is indeed a strange observation. I wonder what "Capture output" might be doing? Forcing the opening of a console window that the SDL framework otherwise closes perhaps?
The Dev-C++ log shows nothing useful because the build was up-to-date. You need to post the log from a Rebuild-all to force a rebuild and show all the useful information. However I think it no longer helps. I have reproduced your problem, and I too cannot get an SDL application to create a console window, so I think that the SDL framework is somehow killing it at runtime.
Because SDL redefines 'main; as a macro, debugging the framework start-up to see how it might be doing that would require rebuilding the SDL code for debug. It is possible I believe to programatically open a console window and redirect stdout to it (which is what I am guessing EditPlus is doing).
The ouptut of the make was what I really wanted to show the 'steps', the make command line alone is not very helpful. You can copy & paste text from a console window you know. However like the Dev-C++ log, I think it may no longer be useful.
Note that using spaces in project and source file paths is a bad idea. Dev-C++ and GNU make do not always cork correctly when faced with spaces in file names and paths.
Clifford