The IDE supports the compiler, and has options for it, so I figure it can do that by itself.
This isn't Linux; this is Windows.
Despite that, using the command line will help you find out what the options are and how to combine them to produce the right stuff.
I [admit that I'm old and] use command-line all the time in Windows to get things done that I could not get done if I tried to do it with GUI. It also doesn't "hide" from you things that you may need to know.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
But this is exactly why I left Linux. I don't like command lines. I hate them. I can use simple stuff. Such as "chkdsk c:" or "calc" or things like that.
But calling compilers and stuff via command line is not my idea of Windows. And apparently it is not the idea of Microsoft either since they build graphical user interfaces and avoid littering things with CLI.
I also believe in Microsoft's vision, and that is why I use Windows. GUI is not optional, it is a requirement. You should never have to use CLI if you don't want to.
Yes and no. Command line interfaces are clunky, but they are precise. And sometimes that is more important than the neatness that you get from the GUI environment.
I started programming before DOS was in general use [I used DOS 2.2 for quite some time too], so I guess I'm more experienced with that.
But be that as it may - I'm not trying to say that you should ALWAYS build the app via command-line - rather that if you figure out how to build it, then you can hopefully fix the Code::Blocks problem in the configuration for Code::Blocks [I presume it's something you can configure].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Yeah, I get what you say, but I'm friggin' tired of it and I'm not going to bother. A program that cannot run from a graphical interface is a broken program.
This is incredibly frustrating, just as with most things multi-platform. Especially when develop on linux.
I know what you mean by the CLI being frustrating but it's not really that bad.
I put the command in the history typing it out once and then just up arrow enter and it's done again when I need to rebuild. If I need it for longer than that, I put it in a makefile and do the history thing with that (make enter up arrow enter).
It's not that hard.
You can also make the IDE call your makefile.
So it's not really that hard. Just some setup.
Did you try adding the compiler to the PATH? That's often considered a "basic" setup step and it usually needs to be done.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
You should try the command line. It doesn't look too difficult.
From http://72.14.253.104/search?q=cache:...&cd=2&gl=ca#21Using SDCC
3.1 Compiling
3.1.1 Single Source File Projects
For single source file 8051 projects the process is very simple. Compile your programs with the following command
This will compile, assemble and link your source file.Code:sdcc sourcefile.c
In other words, something like this might do it . . .
You'll have to find out which directory sdcc was installed in. I'm not sure how it's set up, but you may be able to run the compiler from any directory, if it's in the path.Code:C:\Windows>cd "\Program Files\SDCC" C:\Program Files\SDCC>sdcc sourcefile.c
[edit] Not sure how this applies to Z80 programs, if there are any differences at all. [/edit]
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
As usual, I have no idea on how to call the stupid compiler or linker, because there's no step-to-step guide as how to compile something and the commands, etc.
Here's what Code::Blocks does:
-------------- Build: Debug in Test ---------------
sdcc.exe --out-fmt-ihx -mz80 --profile --verbose --debug --out-fmt-ihx -mz80 --profile --verbose --stack-auto --debug -ID:\Program\SDCC\include -c main.c -o obj\Debug\main.rel
sdcc: Calling preprocessor...
sdcc: Generating code...
sdcc: Calling assembler...
sdcc.exe -LD:\Program\SDCC\lib -o bin\Debug\Test.exe --out-fmt-ihx -mz80 --profile --verbose --debug --out-fmt-ihx -mz80 --profile --verbose --stack-auto --debug obj\Debug\main.rel
obj\Debug\main.o: cannot open.
sdcc: Calling linker...
sdcc: Calling linker...
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
Where is the obj\Debug\main.o dependency introduced?
[edit]And isn't your attempt successful?
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Seems like several things are repeated in the command line - which seems to indicate something being wrong in the settings for the Code::Blocks
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Well, if I try the command line manually, I get "fopen: failed on main.c".
Obviously it can't find the file file. So how to get Code::Blocks to specify the actual path?
No thanks. I've been looking over that damn manual several times but haven't any success.