Feedback regarding makefile for cc65 projects

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Feedback regarding makefile for cc65 projects

Post by Banshaku »

When I first started to use cc65 in the past, one issue was that compiling everything by hand was not very productive and creating a make file for your project was a must. My first makefiles where mostly a list of files that I wanted to compile, which is quite primitive. This required to update the makefile every time you wanted to add a new file to the project.

I have been inactive on those projects for easily 8~10 years and now that I'm working back on some new ones (kids are getting old enough ^^;;), my first issue is that I had to find a way to recompile the C runtime when required. For this, I did some research on how to compile everything in my folder without the need to write files one by one.

At first I was doing it mostly for the runtime but I then decided to make it easier for my source files and data too. This simplified how to manage my files and the way I define my include in my C files too.

Since I'm no expert in make file and did some research on my current needs, there is good chance that some way that I'm doing things may not be adequate. My goal is to have feedback regarding:

- where there could be errors or improper use so I can learn more on the subject
- see how hard is it to use since I think this file could actually help beginners using cc65 projects in C

The archive contains:
- famitone
- neslib
- all the files for the C runtime for version 2.17
- a modified example1.c from Shiru cc65 examples

If should compile without issues if you have 2.17 installed. If you use a different version, you can specify in the makefile the path of your libsrc and it will compile automatically. You just need to update LIBSRC_DIR.

How the folders are structured:
- libs is the folder wich contain libraries. You can add your own too. for now only famitone and neslib.
- src is where you put your source files. It can be either C or S files
- data is where you put your data in c/s/bin files. Technically you could put them in src file too but it's up to you how you want to structure your project.

There is no limit for src/data for sub-directory: it will search for your files and make the proper list. Same things for the includes, if a folder is found, it will create an include path and automatically add it in your includes: no need to have relative path in your C #include or the one in S files anymore. I saw that often in a few examples and it made it difficult to move files around so I decided to make it automated.

I may need to explain more details about the file later if people start using it. I think that it could be used for a pure assembly project too but I didn't try it yet. In that case the runtime part would be unnecessary. Maybe a flag could disable that part in that case or I could guess based on all files extension but that maybe overdoing it.

Common command with the make file:
all -> build both runtime and application
runtime -> build runtime only
run -> run your app with fceux (needs to be in your path)
debug -> start an emulator with debugging capability with your app
clean -> remove only the build folder of the app
clean-runtime -> remove only runtime build folder
clean-both -> remove both runtime build folder and app build folder

Debug right now launch nin.sh, which was as shell script for nintendulator while I was using it on linux and mac. It will require to be updated to your own needs.

My goal was first to make something useful for myself but since I saw a new question about the same issue I had then I decided to check how to make it easy for someone that may not know yet about makefile and cc65, remove that burden and that person could focus on learning the nes innards and the C code only.

It feels great to post on nesdev again and I hope this file will be useful for beginners. I think it should be useful too for people that had issues with the provided runtime in Shiru examples that is now not compatible with the latest version.

I think is all of Shiru's example that motivated me to make that makefile. Those examples helped me figure out where to look and how to do things so I'm grateful that Shiru shared them. Now I feel that sharing what I made from that is the least I can do.
Attachments
example_makefile.zip
(268.91 KiB) Downloaded 241 times
cppchriscpp
Posts: 102
Joined: Fri Dec 27, 2013 4:28 pm

Re: Feedback regarding makefile for cc65 projects

Post by cppchriscpp »

Hey - nice to see someone else messing with makefiles and C. Thanks for sharing!

I use one in my nes-starter-kit project if you'd like a different example to look at; we're doing a lot of similar things: https://gh.nes.science/nes-starter-kit/ ... r/makefile (Yours is better commented/explained than mine is, as a warning)

One thing you might find particularly useful is a snippet I found called rwildcard (recursive wildcard) - it lets you include matching files in a directory and all subdirectories. (So you could include src/main.c and src/graphics/title.c, for example.) I found it from here: https://stackoverflow.com/a/18258352

I like how you did the FT_DEFINES variable - if I add more of that type of thing I'll probably adopt that pattern.

Thanks again for sharing
Last edited by cppchriscpp on Fri Jan 26, 2024 10:09 pm, edited 1 time in total.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Feedback regarding makefile for cc65 projects

Post by Banshaku »

You're welcome!

I remember checking you samples when first trying to figure out how to make code in C for the nes. My main issue is for quick testing with the current sample files, if I moved one file to my own folder then all the includes add issues because of the relative path. I'm not sure if this is something common in C since I didn't write C code for years but since a beginner may have issues with this aspect, I decided to add automatically all folder as include path. This way, even thought it may be seen like a brute force way to avoid include issues, it does simplify the project by a lot. All include paths, even for incbin, doesn't require any relative path at all: you just write .incbin 'myfile.chr' from your files in src even though the bin file could be in data, libs, src, src/myfolder/mydata etc.

A beginner, when starting on a system like the nes, unless that person has years of experience in development, will not know about all those small details and may get discouraged. It is better to hide all those complicated part until that person gets comfortable enough to figure out those parameters on their own.

Hey, I remember seeing that example while searching for recursive sub-folder :) As for the example, one issue when you try to add recursive folder, it won't add the root one. This is a known issue and this is why you have to add manually the root files then the sub-folder files. In the example, it was simplified by adding a function that does all pattern to make it easier every time you need to retrieve the files in a folder. I decided not to add a function in my case since I was not familiar with them yet and it could make it harder for someone that is not familiar with make file too.
cppchriscpp
Posts: 102
Joined: Fri Dec 27, 2013 4:28 pm

Re: Feedback regarding makefile for cc65 projects

Post by cppchriscpp »

Ah, I completely missed that detail; that's cool!

I'd be a little afraid it would cause confusion if you had two files in different subdirectories with the same name, but that's probably pretty rare. I don't think I've ever done that for an NES project. A comment somewhere prominent explaining that caveat could probably avoid the problem too.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Feedback regarding makefile for cc65 projects

Post by Banshaku »

I rarely use the same name for a file inside a project so at first I overlooked that aspect but if you start to use libraries from other people it may become an issue. Good find, I will document that limitation. I think it is still a good compromise to reduce the complexity when accessing the files.

Now that I know more about makefile I need to recheck yours to see if there is something that I may now use from it :)
Post Reply