#24780 - wiz - Wed Aug 11, 2004 1:44 pm
Hi!
I have now tried Context and UltraEdit for my programming GUI..
And I have managed to configure them both to compile and run my code like my batch file used to do in 3 steps: (I wish I could just have 1 button to do it all)
GCC -o "%p%F.obj" "%n"
OBJCOPY -O binary "%p%F.obj" "%p%F.gba"
VBA "%p%F.gba"
- There isnt a way to make it do all that in one go is there?
My actual question is that I would really like to split up my source files so I dont need to scroll/search as much when Im only looking at my main code (functions like WaitVBL, which could be used in all projects, would be cleaner in a seperate .c file)
Execpt I have no idea how to set up the editor(s) to do this?
Can someone show how they have set theirs up please? Or do I have to have everything in one .c file?
Cheers!
#24782 - isildur - Wed Aug 11, 2004 2:41 pm
Maybe you could place your commands in a .BAT file and make it execute that.
#24785 - wiz - Wed Aug 11, 2004 3:32 pm
Hi thanks for the idea, unfortunately that would mean I would need to make a seperate batch file for each project..
I'm wondering how to configure the editor to accept multiple source files, so I can keep functions tidy and use the same source files for each project rather than copy it everytime etc.
#24787 - keldon - Wed Aug 11, 2004 4:02 pm
Shove your source files into the include directory; so you simply do something like #include<myLib/gfx.h>
Also if you just want to have more than one source file for your project; you only need to using (again) the include keyword, as such:
---
This is your directory where the files are:
- main.c
- level1.c
---
now in main.c you simply write:
and the code from level1.c will be included into main.
I have not used your editor; but editplus is superb for handling projects.
#24789 - SmileyDude - Wed Aug 11, 2004 4:31 pm
ack! that's horrible advice! You should never #include code -- only prototypes, struct/class definitions, and constants/#defines.
What you should ideally be doing is creating a makefile for each project, or barring that, at least a build batch file. Personally, I prefer make, but it can be intimidating to new users.
The main reason you want to make a makefile or batch file is that you separate your build from your editor. If you somehow configure your editor to build your project with multiple files, when you decide that you like some other editor better, you'll have to re-work your build process for each project. With makefiles or batch files, you just figure out how to invoke make/build.bat from the new editor, and everything just works.
I know it's a pain to do, but it will really pay off later. For my gba development, I created a script to create a new project. It automatically sets up a new directory with my preferred sub-directories, drops in a makefile, and even drops in a main.c. It took a little bit to setup (about an hour or two), but now I can create a new project almost instantly.
Another recomendation I would like to make is to setup a project/directory for your shared code. I waited over a year before I setup a library for the GBA, and once I did, it made things much simpler :)
Good luck!
_________________
dennis
#24793 - keldon - Wed Aug 11, 2004 5:14 pm
Using #include has nothing to do with not using batch files.
Besides, what's wrong with using #include in this case? It's all nice creating a script to create a new project; but let's not shoot at the rabit with a nuke, when an include will do fine here.
#24795 - poslundc - Wed Aug 11, 2004 5:37 pm
| keldon wrote: |
| Using #include has nothing to do with not using batch files. |
No, but it is an invitation to a programming disaster.
| Quote: |
| Besides, what's wrong with using #include in this case? It's all nice creating a script to create a new project; but let's not shoot at the rabit with a nuke, when an include will do fine here. |
You should also be careful not shoot at the rabbit with a screwdriver. #include was not intended for this purpose, and the gcc manuals are clear on that.
#including C files opens several cans of worms:
- Introduces possiblities for naming conflicts (functions, variables, macros, etc.)
- Increased compilation time, harder to track down errors in source, impossible to debug with source-level debuggers
- Heavy risk of multiple-inclusion or cyclical-inclusion if the project becomes at all complicated
- Difficult to migrate to a properly-encapsulated format
- Negates the benefits of encapsulation (such as information hiding)
- Requires full recompiles of source instead of only partial recompiles (relevant to makefiles more than batch files)
- It's downright sloppy, spaghetti coding, and no project needs that, however small.
Furthermore, in the simplest case, the only difference in building a properly modularized project is adding the names of the additional modules to the gcc command line. What's so nuclear about that?
Dan.
#24799 - sajiimori - Wed Aug 11, 2004 6:26 pm
I use ConTEXT. F9 runs "make", F10 runs "make run", and F12 runs "make clean". If you set up all your projects the same way, you can make a generic makefile and run "make -f your_makefile.mk" instead. Since I use ConTEXT to write both PC and GBA programs (in various languages) that isn't really an option for me. Each of my projects has its own makefile, which is the traditional way of doing things.
#24849 - wiz - Thu Aug 12, 2004 11:13 am
Thanks very much for all the replies and suggestions,
After a long thought I now can see a make file for each project would be a very good idea.
Which leads me on to my next question...
is a Makefile just a "batch file" or is it a special file for the gcc compiler?
from what I see in searches its not too simple to make one =/
#24859 - sajiimori - Thu Aug 12, 2004 5:55 pm
The purpose of make (as opposed to batch files) is to selectively rebuild the parts of a project that need rebuilding. It does this by checking the modification dates of the input files and comparing them to the dates on the output files (if they even exist yet). If the input file has been modified more recently, then the output file needs to be rebuilt.
If you have a file called mypicture.bmp and you want to convert it to a raw binary called mypicture.gba, you could express the input and output files this way:
| Code: |
mypicture.gba: mypicture.bmp
|
The thing on the left is called the "target", and the thing on the right is the "prerequisite". The whole line is called a "rule". Rules can have multiple targets and prerequisites, such as if you had a tool to convert multiple .bmp files to a pair of a .c file and an .h file:
| Code: |
all_bmps.c all_bmps.h: graphic1.bmp graphic2.bmp graphic3.bmp
|
Of course, I haven't mentioned how to actually run the commands that produce the targets. Let's say you have a tool called bmp2gba, and you're going to use that for the first rule above. You could finish the rule this way:
| Code: |
mypicture.gba: mypicture.bmp
bmp2gba mypicture.bmp mypicture.gba
|
The indented text will be run on the command line, and I call it the "body" of the rule but I don't know if that's standard. Note that you have to use a hard tab, so make sure your editor doesn't convert tabs to spaces.
There's nothing that says you have to actually create the target in the body:
| Code: |
mypicture.gba: mypicture.bmp
echo I don't feel like doing work right now.
|
The rule will get executed if mypicture.gba doesn't exist, or if it's older than the prerequisite, so if you don't actually create the file the rule will be run every time you run the makefile, but make won't complain.
Rules can be chained: If A depends on B, and B depends on C, then if C changes then B will be rebuilt, which will cause A to be rebuilt.
You can write generic rules (called "implicit rules") that match patterns in filenames to determine how one kind of file is converted to another kind. Here's how you might tell make how to convert any .bmp file to a .gba file:
| Code: |
%.gba: %.bmp
bmp2gba $< $@
|
% is the wildcard obviously. $< is the input file, and $@ is the target -- these are worth memorizing. After this implicit rule is in place, you can have anything depend on a .gba file, and make will automatically look for a .bmp file to convert to .gba in order to satisfy the prerequisite.
So, if you had some .bmp files, and bmp2gba, and a program to take multiple .gba files and make an archive out of them, you could convert all the .bmp files to an archive this way:
| Code: |
archive.bin: graphic1.gba graphic2.gba graphic3.gba
make-archive graphic1.gba graphic2.gba graphic3.gba
%.gba: %.bmp
bmp2gba $< $@
|
Make will look for the prerequisite .gba files, and when it doesn't find them, it will look for a rule to build them. Then it will see the bmp->gba rule, and search for corresponding .bmp files, then run the rule on them to satisfy the prerequisite.
Duplicating the list of .gba files is ugly. Use variables to clean things up:
| Code: |
GBA_FILES = graphic1.gba graphic2.gba graphic3.gba
archive.bin: $(GBA_FILES)
make-archive $(GBA_FILES)
|
Make comes with some implicit rules built-in, notably for converting .c files to .o files. To build a PC executable using GCC, you could do this:
| Code: |
OBJS = main.o file1.o file2.o
my_program.exe: $(OBJS)
gcc -o my_program.exe $(OBJS)
|
If main.c includes file1.h and file2.h, make sure to list those as prerequisites so that when they change, main.o will be rebuilt.
| Code: |
main.o: file1.h file2.h
|
GCC can automatically generate such rules for you if you use the -M flag.
#24862 - dagamer34 - Thu Aug 12, 2004 6:28 pm
| sajiimori wrote: |
The purpose of make (as opposed to batch files) is to selectively rebuild the parts of a project that need rebuilding. It does this by checking the modification dates of the input files and comparing them to the dates on the output files (if they even exist yet). If the input file has been modified more recently, then the output file needs to be rebuilt.
If you have a file called mypicture.bmp and you want to convert it to a raw binary called mypicture.gba, you could express the input and output files this way:
| Code: |
mypicture.gba: mypicture.bmp
|
The thing on the left is called the "target", and the thing on the right is the "prerequisite". The whole line is called a "rule". Rules can have multiple targets and prerequisites, such as if you had a tool to convert multiple .bmp files to a pair of a .c file and an .h file:
| Code: |
all_bmps.c all_bmps.h: graphic1.bmp graphic2.bmp graphic3.bmp
|
Of course, I haven't mentioned how to actually run the commands that produce the targets. Let's say you have a tool called bmp2gba, and you're going to use that for the first rule above. You could finish the rule this way:
| Code: |
mypicture.gba: mypicture.bmp
bmp2gba mypicture.bmp mypicture.gba
|
The indented text will be run on the command line, and I call it the "body" of the rule but I don't know if that's standard. Note that you have to use a hard tab, so make sure your editor doesn't convert tabs to spaces.
There's nothing that says you have to actually create the target in the body:
| Code: |
mypicture.gba: mypicture.bmp
echo I don't feel like doing work right now.
|
The rule will get executed if mypicture.gba doesn't exist, or if it's older than the prerequisite, so if you don't actually create the file the rule will be run every time you run the makefile, but make won't complain.
Rules can be chained: If A depends on B, and B depends on C, then if C changes then B will be rebuilt, which will cause A to be rebuilt.
You can write generic rules (called "implicit rules") that match patterns in filenames to determine how one kind of file is converted to another kind. Here's how you might tell make how to convert any .bmp file to a .gba file:
| Code: |
%.gba: %.bmp
bmp2gba $< $@
|
% is the wildcard obviously. $< is the input file, and $@ is the target -- these are worth memorizing. After this implicit rule is in place, you can have anything depend on a .gba file, and make will automatically look for a .bmp file to convert to .gba in order to satisfy the prerequisite.
So, if you had some .bmp files, and bmp2gba, and a program to take multiple .gba files and make an archive out of them, you could convert all the .bmp files to an archive this way:
| Code: |
archive.bin: graphic1.gba graphic2.gba graphic3.gba
make-archive graphic1.gba graphic2.gba graphic3.gba
%.gba: %.bmp
bmp2gba $< $@
|
Make will look for the prerequisite .gba files, and when it doesn't find them, it will look for a rule to build them. Then it will see the bmp->gba rule, and search for corresponding .bmp files, then run the rule on them to satisfy the prerequisite.
Duplicating the list of .gba files is ugly. Use variables to clean things up:
| Code: |
GBA_FILES = graphic1.gba graphic2.gba graphic3.gba
archive.bin: $(GBA_FILES)
make-archive $(GBA_FILES)
|
Make comes with some implicit rules built-in, notably for converting .c files to .o files. To build a PC executable using GCC, you could do this:
| Code: |
OBJS = main.o file1.o file2.o
my_program.exe: $(OBJS)
gcc -o my_program.exe $(OBJS)
|
If main.c includes file1.h and file2.h, make sure to list those as prerequisites so that when they change, main.o will be rebuilt.
| Code: |
main.o: file1.h file2.h
|
GCC can automatically generate such rules for you if you use the -M flag. |
Really nice post!! I learned a lot of things! :)
tepples, this should be FAQ'ed or something. In fact, making the FAQ downloadable so people have easy access would make it even better.
_________________
Little kids and Playstation 2's don't mix. :(
#24875 - tepples - Thu Aug 12, 2004 9:06 pm
| dagamer34 wrote: |
| tepples, this should be FAQ'ed or something. In fact, making the FAQ downloadable so people have easy access would make it even better. |
Good idea.
sajiimori: May I do this?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#24877 - Cearn - Thu Aug 12, 2004 9:26 pm
| dagamer34 wrote: |
| tepples, this should be FAQ'ed or something. In fact, making the FAQ downloadable so people have easy access would make it even better. |
Maybe links to the manuals might help too, either to the ones at gnu.org or to CHM formatted ones found here.
Also, the FAQ is already downloadable. Just like every other web page :P
#24879 - dagamer34 - Thu Aug 12, 2004 9:58 pm
| Cearn wrote: |
| dagamer34 wrote: | | tepples, this should be FAQ'ed or something. In fact, making the FAQ downloadable so people have easy access would make it even better. |
Maybe links to the manuals might help too, either to the ones at gnu.org or to CHM formatted ones found here.
Also, the FAQ is already downloadable. Just like every other web page :P |
Funny...
Seriously though, some people may never find the forums here, some just stay at the main site. People just happen to stumble across the FAQ.
People shouldn't have to find a FAQ, but you have to go through at least 2 links before you can get to it. And thats if you know where it is...
A permanent link should be put on the main page. Just my 2 cents...
_________________
Little kids and Playstation 2's don't mix. :(
#24881 - sajiimori - Thu Aug 12, 2004 10:08 pm
Anybody can use that post however they want. It should probably mention the CC variable, since it's not clear how make would know to run 'gcc' (and in fact the example would run the default 'cc').
#24884 - tepples - Thu Aug 12, 2004 10:30 pm
| dagamer34 wrote: |
| Seriously though, some people may never find the forums here, some just stay at the main site. People just happen to stumble across the FAQ. |
Darn right. I'd suggest linking to the Beginners' FAQ at the top of each page, right next to the existing phpBB FAQ link.
Anyway, I've tossed sajiimori's tutorial up here and have linked to it from the Beginners' FAQ.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#24885 - ScottLininger - Thu Aug 12, 2004 10:50 pm
I think dagamer is right... when I first visited this site the forums were the last thing I visited, yet that's where all of the good content is. Anything that can be done to make the forums and the FAQs more visible is a great thing.
-Scott