This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Universal Makefile for CC65

Universal Makefile for CC65
by on (#77300)
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.

by on (#77435)
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...
Code:
msgs.s: msgs.py

msgs.py:
   python msgs.py

...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?

by on (#77436)
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...
Code:
msgs.s: msgs.py

msgs.py:
   python msgs.py

...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?


Try this:

Code:
msgs.s: msgs.py
    python msgs.py

by on (#77462)
Ah, thanks clueless, that works perfectly. :)

by on (#77466)
miau wrote:
Ah, thanks clueless, that works perfectly. :)


You're welcome.

The general syntax is something like this:
Code:
<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

by on (#77472)
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?

by on (#78790)
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?

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. :)

by on (#78802)
Yeah, that was the problem. I forgot to update my post, but thanks again!
I must have overlooked the "-g" when I compared the makefiles myself...
Re: Universal Makefile for CC65
by on (#79425)
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.


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.

Code:
$ 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


Sure enough, I get the same issue when trying it in Cygwin.

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".

by on (#79429)
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?

by on (#79433)
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?

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.

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.

by on (#79435)
Cygwin works if you just need a bash shell in windows, btw.

Actually, though, I think mkdir is an alias for new-item in powershell if you have win7. And you can run cygwin in powershell! Sorry, just dig the blue screen. :P

by on (#79437)
Bellum wrote:
Cygwin works if you just need a bash shell in windows, btw.


I must not have worded my concern clearly...sorry. I'll try again.

I get the same results within Qt or within Cygwin.

CC65 is in my path:
Code:
$ which cl65
/cygdrive/c/Program Files (x86)/cc65-snapshot/bin/cl65


But when I hit up Cygwin with "make" *or* when I QProcess a "make" from within Qt (yes, with the process environment set up appropriately), using that universal makefile, I get the same results as I showed in the original posting.

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:
# 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


And the "problem"...CC65 installation sets CC65_HOME to:

Code:
$ echo $CC65_HOME
C:\Program Files (x86)\cc65-snapshot


If I change the above quoted portion of the universal makefile to:
Code:
  CC := cl65


Everything's fine in Cygwin and Nesicide.

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.

by on (#79443)
cpow wrote:
So my question was: should I fix it for Windows and update the Wiki?

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.