Universal Makefile for CC65
Moderator: Moderators
Universal Makefile for CC65
I didn't become aware of this until recently, thought I would post it here: http://wiki.cc65.org/doku.php?id=cc65:project_setup
It's an "universal" Makefile for use with CC65 (+CA65) projects. Basically all you have to do is take that Makefile, drop it in a directory, make a directory called "src", add your sources in there (extension .s or .c) and invoke "make". The cool thing is that it automatically keeps track of dependencies, so if for example you .incbin "foo.chr" in "bar.s", whenever "foo.chr" changes, it'll automatically recompile "bar.s". This requires the dev version of CC65 however.
To adapt it to NES projects where we usually use a customized memory config, set TARGETS to "nes" and add "-t none -C foo.cfg" to LDFLAGS.
It's an "universal" Makefile for use with CC65 (+CA65) projects. Basically all you have to do is take that Makefile, drop it in a directory, make a directory called "src", add your sources in there (extension .s or .c) and invoke "make". The cool thing is that it automatically keeps track of dependencies, so if for example you .incbin "foo.chr" in "bar.s", whenever "foo.chr" changes, it'll automatically recompile "bar.s". This requires the dev version of CC65 however.
To adapt it to NES projects where we usually use a customized memory config, set TARGETS to "nes" and add "-t none -C foo.cfg" to LDFLAGS.
Just set this up for my own project.
This is a great help, thanks for posting! Stitching something like it together with the help of google would have taken ages.
How would I go about adding a manual dependency, though?
E.g., I have a python script (msgs.py) that generates an assembly source file (msgs.s) which is included by another source file.
If msgs.py has been changed, i.e. its modified date is greater than that of msgs.s, python needs to be called so a new msgs.s will be created.
This...
...did not work.
I'm not great at Makefiles, so I am probably missing something obvious. Is it even possible to override dependencies like this?
This is a great help, thanks for posting! Stitching something like it together with the help of google would have taken ages.
How would I go about adding a manual dependency, though?
E.g., I have a python script (msgs.py) that generates an assembly source file (msgs.s) which is included by another source file.
If msgs.py has been changed, i.e. its modified date is greater than that of msgs.s, python needs to be called so a new msgs.s will be created.
This...
Code: Select all
msgs.s: msgs.py
msgs.py:
python msgs.pyI'm not great at Makefiles, so I am probably missing something obvious. Is it even possible to override dependencies like this?
Try this:miau wrote:Just set this up for my own project.
This is a great help, thanks for posting! Stitching something like it together with the help of google would have taken ages.
How would I go about adding a manual dependency, though?
E.g., I have a python script (msgs.py) that generates an assembly source file (msgs.s) which is included by another source file.
If msgs.py has been changed, i.e. its modified date is greater than that of msgs.s, python needs to be called so a new msgs.s will be created.
This......did not work.Code: Select all
msgs.s: msgs.py msgs.py: python msgs.py
I'm not great at Makefiles, so I am probably missing something obvious. Is it even possible to override dependencies like this?
Code: Select all
msgs.s: msgs.py
python msgs.py
You're welcome.miau wrote:Ah, thanks clueless, that works perfectly.
The general syntax is something like this:
Code: Select all
<target> <colon> <white space> <space separated list of dependencies> <cr>
<tab> <commands to bring target up to date> <cr>
(optional) <tab> <more commands...> <cr>
<cr> // marks end of command sequence
Finally gave this a try and I'd say it was worth it ;3
Thanks for posting it here, 'cause I (and maybe many others) would have never found it!
Edit:
I have a little problem.
Since I use the new Makefile, I only get the "standart" label names in the VICE .lbl file and all the labels I named myself in my source files are not included.
I compared my old Makefile with this new one, but I can't find the difference that would cause this problem.
Anyone else had this problem?
Could it be, that I now use a newer version of the cc65 package?
Thanks for posting it here, 'cause I (and maybe many others) would have never found it!
Edit:
I have a little problem.
Since I use the new Makefile, I only get the "standart" label names in the VICE .lbl file and all the labels I named myself in my source files are not included.
I compared my old Makefile with this new one, but I can't find the difference that would cause this problem.
Anyone else had this problem?
Could it be, that I now use a newer version of the cc65 package?
Did you include debug information in the object files with the "-g" switch? It's probably best if you post your old Makefile here so we don't need to play the guessing game.Grumskiz wrote: I have a little problem.
Since I use the new Makefile, I only get the "standart" label names in the VICE .lbl file and all the labels I named myself in my source files are not included.
I compared my old Makefile with this new one, but I can't find the difference that would cause this problem.
Anyone else had this problem?
Could it be, that I now use a newer version of the cc65 package?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: Universal Makefile for CC65
I'm integrating this into Nesicide, but I'm having an issue with Windows' annoying path problems. The default CC65 install location is "C:\Program Files (x86)". Unfortunately this causes problems when I try to invoke make...it complains about the '(' and exits.thefox wrote:To adapt it to NES projects where we usually use a customized memory config, set TARGETS to "nes" and add "-t none -C foo.cfg" to LDFLAGS.
Code: Select all
$ make
C:\Program Files (x86)\cc65-snapshot/bin/cl65 -t nes -c --create-dep obj/nes/mai
n.d -o obj/nes/main.o src/main.s
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `C:\Program Files (x86)\cc65-snapshot/bin/cl65 -t nes -c --
create-dep obj/nes/main.d -o obj/nes/main.o src/main.s'
make: *** [obj/nes/main.o] Error 1
Should I fix it and update that Wiki?
EDIT: The line breaks are from my cut-paste from my Cygwin window and are not part of "the problem".
Yeah, this is probably the best thing to do. You should be able to do it with setProcessEnvironment method of QProcess. The makefile seems indeed to be faulty in that regard.tepples wrote:Have you tried adding C:\Program Files (x86)\cc65-snapshot\bin to your PATH environment variable and then just calling it as 'cl65' rather than giving the full path?
BTW it also will not work with cmd.exe as the shell, as it assumes mkdir is the *nix mkdir, and cmd.exe doesn't allow overriding its default internal mkdir (and rmdir). I've made a modified version of the Makefile that works with cmd.exe (as well as *nix shells) in case anybody is interested.
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
I must not have worded my concern clearly...sorry. I'll try again.Bellum wrote:Cygwin works if you just need a bash shell in windows, btw.
I get the same results within Qt or within Cygwin.
CC65 is in my path:
Code: Select all
$ which cl65
/cygdrive/c/Program Files (x86)/cc65-snapshot/bin/cl65
So my question was: should I fix it for Windows and update the Wiki?
By the way, Qt had no problem with QProcess calling "ca65" or "ld65" from within Nesicide, it never complained that the path had spaces or ()'s. It also doesn't complain that "make" itself is in a path with spaces...probably because it found the target using my PATH, so it didn't have to expand it and cause problems.
The problem is the way the universal makefile creates the CC variable.
Code: Select all
# On Windows it is mandatory to have CC65_HOME set. So do not unnecessarily
# rely on cl65 being added to the PATH in this scenario.
ifdef CC65_HOME
CC := $(CC65_HOME)/bin/cl65
else
CC := cl65
endif
Code: Select all
$ echo $CC65_HOME
C:\Program Files (x86)\cc65-snapshot
Code: Select all
CC := cl65
I think the CC65 toolchain installer adds the tool bin to PATH by default (I didn't have to do it manually anyway), so I'm not sure why there needs to be Windowsy stuff in the universal makefile.
Probably better to just notify Oliver, you can get his email from CC65 mailing list (replace "1" with "@" in the email address). I have no idea why the Makefile states that it's mandatory to have CC65_HOME set on Windows, I certainly don't (installed it manually) and CC65 has been working fine. And it's obviously in the wrong assuming the path can't contain parenthesis.cpow wrote:So my question was: should I fix it for Windows and update the Wiki?