| |
Burglar
Registered: Dec 2004 Posts: 1031 |
Cross Development using Makefile
Weekend didn't even start for most of you yet, but here it is ;)
Cross Development using Makefile
comments and improvements are of course very welcome.
enjoy and may your build times be short!
make -j16 |
|
... 37 posts hidden. Click here to view all posts.... |
| |
Burglar
Registered: Dec 2004 Posts: 1031 |
@Dr.J, ah yes Windows... groepaz and JackAsser already told you, but, use cygwin! ;)
That's the best option, or just install linux or get a mac.
GNU make runs on Linux/BSD/OSX/*nix and probably more.
nmake might do the tricks you need, but I cant really say as I don't use
windows anymore. Also, stackoverflow has some info on it that might help you too.
@spider, as BlackWine said, you rm/delete the object right after you build it ;)
You'll want to do one step at a time, not combine them.
I would do it like this, with a seperate compile rule and a seperate pack rule.
OBJECTS=loader.exo rasters.exo
# a .prg is a compiled .asm
%.prg: %.asm $(LIBS)
$(ASS) $(ASSFLAGS) $<
# a .exo is a packed .prg
%.exo: %.prg
$(PACKER) $(PACKERFLAGS) $< -o $@
all: $(OBJECTS)
loader.prg: loader.asm include/gemischt.prg include/randomtab2.prg
rasters.prg: rasters.asm include/ballsprites.spr include/border-empty-sprites.spr include/demotune01.c64.prg include/mydpetsciilogo.prg include/spider-logo-sprites.spr
clean:
rm -f *.exo
|
| |
King Durin Account closed
Registered: Oct 2007 Posts: 85 |
GNU Make for Win32 works just fine, especially if you also install the GNU For Win32 library on your system and put the gnu\bin folder on the path. Cygwin, etc, not necessary. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11116 |
one day also you will come to the point where things do not actually quite work as intended - and cygwin is it then =) i'd just recommend to use it from the start, because it will save you a lot of frustrating WTF moments. |
| |
soci
Registered: Sep 2003 Posts: 473 |
Sorry for digging an old thread up but I wanted to share this just in case it's useful to some.
For projects with a lot of files manually managing the prerequisite lists started to get annoying. Especially if I missed something. I learned that this can be automated by including the dependency list from an external file.
Fine my assembler had the "-M" option to write dependencies into a file which I normally copy-pasted into the Makefile. Including it sort of worked but failed when something was removed or renamed as those files were now missing. Dummy rules could have prevented this of course but were not present either. So I had to create a new "--make-phony" option recently to produce them and now it works.
Here's a minimal Makefile:
demo.prg: demo.asm demo.dep
64tass --make-phony -M demo.dep $< -o $@
demo.dep:
-include demo.dep
The target needs to depend on the main source file and the dependency list file. As the dependency list file itself may not exists at first there's a dummy rule for this and the include is prefixed with a "-" to prevent errors. |
| |
tlr
Registered: Sep 2003 Posts: 1714 |
Very useful!
I'm considering switching assembler for superfluid as the current dasm flow is rather messy. Automatic dependencies would be helpful as there are a lot of files to track. |
| |
MagerValp
Registered: Dec 2001 Posts: 1056 |
Agreed, it's a huge time saver. ca65 has a --create-dep option that does the same thing. |
| |
Oswald
Registered: Apr 2002 Posts: 5017 |
what hapens if demo.dep doesnt exist yet, or if I change the includes in the src, and make goes for the first time around ? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11116 |
usually you have seperate rule that just generates the .dep file when it does not exist. and you trigger that rule manually when the includes change (or just always if its quick enough) |
| |
soci
Registered: Sep 2003 Posts: 473 |
Nothing interesting happens. If a file is missing with a dummy rule it's a change and of course modifying an include line in one of the sources is a change. The resulting compilation creates an updated demo.dep file and all is well.
A separate target may be necessary if dependency generation is not done at the same time as the compilation. For example when it's done by a separate program and it's somehow slow.
Until now I too thought this should be done in a separate target like Groepaz said and so there were no dummy rules generated. After all in that workflow you generate them manually and therefore there won't be any missing files. And if there were it was the reason to run it ;)
But generating them always is fast enough for me. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11116 |
seperate rule is just a convention from old GNU times i think, when it took quite a while :) |
Previous - 1 | 2 | 3 | 4 | 5 - Next |