| |
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 |
|
| |
Stone
Registered: Oct 2006
Posts: 168 |
I had a quick look and I have one comment: What you refer to as labels are normally called variables, (or even macros by some). Things like $@ and $< are called automatic variables. Using the commonly accepted terms for these things is useful when trying to find further information on the 'net. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Thanks! It's updated ;) |
| |
Hermit
Registered: May 2008
Posts: 208 |
Great to have this kind of topic here. thx for it, must save a lot of googling time for some people.
Might be useful to mention 'for' loops for command-line tools that doesn't support batch processing (if it doesn't affect the purity of the article for 'make'). I'm not sure about CC1541 but I couldn't find a correct batch processing to assemble the SID-Wizard d64 image with executables and examples, so I ended up solving it by 'for' loops lately.
This btw possibly makes the makefile platform-dependent (btw it's already platform-dependent due to slashes/back-slashes I guess, or it might provide bash commands in certain toolchains - e.g.: cmake).
Based on the basic form to iterate through directory:
in linux-bash: for <variable> in <directory/filetype-filter> ; do <commands - if more, they're separated by semicolons> ; done ;
in M$ batch : for %%<variable> in (<directory\filetype-filter>) do (<batch commands to perform)>)
An extract from my current makefiles how I do it (though there might be a better way, dunno):
for sng2swm I use this (bash syntax):
for inputfile in $(EXASWMDIR)/sng-imports/*.sng ; do $(BINARYDIR)/$(SNG-CONVERTER) $$inputfile $${inputfile%.*}.swm.prg $(KUSS) ; done ;
for M$-batch:
for %%i in (%EXASWMDIR%\sng-imports\*.sng) do ( %SNG-CONVERTER% %%i %%~dpni.swm.prg > nul )
for cc1541 I use this (on previously created .d64 file):
for inputfile in $(EXASWMDIR)/*.swm.prg ; do outputfile=$${inputfile##*/} ; \
$(CBMDISK) -attach $@ -write $$inputfile $${outputfile%.*} ; done;
in M$-batch:
for %%i in (%EXASWMDIR%\*.swm.prg) do (
%CBMDISK% -attach %BINARYDIR%\%APPNAME1%-%APPVERSION%-disk.d64 -write %%i %%~ni > nul
)
It is worth to mention the other small tools to enhance readibility:
\ in bash-based makefile performs a line-break
$${..#..%.} commands in bash can be used for string-alterations (e.g. cutting the extension, etc..) - it has simpler form in batch, e.g. %%~ni
I however couldn't find out the proper way to give the dependencies of the files used by the 'for' loops. For instance I used "$(EXASWMDIR)/" as folder-content dependency but it didn't worked in the way I exactly wanted.
Kinda out-of-topic, but I'd be glad to have a Turbo Chameleon 64 programming topic at Codebase64. I tried experimenting with its VGA mode based on its good documentation, but some working source code could always make brainwork easier, e.g. to see what is the preferred order for writing registers...
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Looks excellent, Burglar! I have no excuse for not trying it out now. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
@Cruzer, great ;) if you run into any problems, gimme a shout.
@Hermit, using for loops like you are, you're just redoing everything
whenever you need to build. Also when it isn't needed.
Let me enhance your sng2swm building:
SNG2SWM=bin/sng2swm
SNGSRC=$(shell find ./sng-imports -name '*.sng')
SWMOBJ=$(SNGSRC:.sng=.swm.prg)
%.swm.prg: %.sng
$(SNG2SWM) $< $@
all: $(SWMOBJ)
clean:
rm -f $(SWMOBJ)
Now, "make all" will convert all .sng files to .swm.prg.
If you modify or add one, then that's the only one that will be converted
when you run "make all" again.
You can now also build in parallel.
The c1541 (thats what you use, cc1541 is a different tool by JackAsser)
issue is more complex as there is only one targetfile with multiple inputfiles.
So for now, I'll just advice to write it out in the Makefile.
Will save some headaches ;) |
| |
Dr.j
Registered: Feb 2003
Posts: 276 |
Hey There Burglar
I am a newcommer in Building shell commands to build files
and i didn't get into the bottom line of this thread.
sorry for the "pain-in-the ass" question:
where can i find this tool "MakeFile" ? didn't see any d/l . or is it a text file we edit ? i always used batch (MS) commands like "XXX.BAT"
and i got old one for compiling from Kickass and run in Winvice , can you show me Batch commands (MS) to
crunch with exomizer and to create/edit file with cc1541
with some info. about the commands ?
|
| |
Shine
Registered: Jul 2012
Posts: 327 |
Hi Alex,
maybe you looking for:
http://gnuwin32.sourceforge.net/packages/make.htm |
| |
Dr.j
Registered: Feb 2003
Posts: 276 |
Thanks Andy :-)
I gonna d/l it soon .
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
dr.j has brought up an important point .... if you are stuck on windows for some reason, you need a "how to install and use cygwin" tutorial aswell, else even simple stuff like rm -f might not work correctly =)
(and dont even think about using make without a proper bash shell. yes it works for some simple stuff. BUT it will make your head explode once you get to the more advanced stuff, trust me) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: dr.j has brought up an important point .... if you are stuck on windows for some reason, you need a "how to install and use cygwin" tutorial aswell, else even simple stuff like rm -f might not work correctly =)
(and dont even think about using make without a proper bash shell. yes it works for some simple stuff. BUT it will make your head explode once you get to the more advanced stuff, trust me)
Actually you get quite far by installing nmake from microsoft and then unixtools for windows. But then again cygwin is a more general approach, pity the io-wrapper is so damn slow. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
"Actually you get quite far by installing nmake from microsoft and then unixtools for windows."
lets say you can make some things work. until you notice that some things only work halfway as intended. and then you will encounter something that doesnt work at all and install cygwin. =)
and ofcourse nmake works differently from gnu make. not to say it seriously sucks arse :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
:P |
| |
Trap
Registered: Jul 2010
Posts: 222 |
Thank you Burglar for writing this.
Excellent stuff!!! |
| |
spider-j
Registered: Oct 2004
Posts: 444 |
Thanks for the rant, Burglar! I finally wrote my first Makefile \o/
But I've got the problem that make everytime builds everything from scratch; even when none of the source or dependencies files was changed (i.e. when I type 'make' two times in the shell like you wrote in the rant).
Here's my Makefile:
ASS=acme
ASSFLAGS=-v4
LIBPATH=/usr/share/acme/6502
LIBS=$(LIBPATH)/kernal.a $(LIBPATH)/static.a $(LIBPATH)/macros.a
PACKER=exomizer
PACKERFLAGS=sfx 2064 -n
BINARYDIR=../bin
OBJECTS=loader.prg rasters.prg
RM=rm -f
all: $(OBJECTS)
%.prg: %.asm $(LIBS)
$(ASS) $(ASSFLAGS) $<
$(PACKER) $(PACKERFLAGS) -o $(BINARYDIR)/$@ $@
$(RM) $@
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) $(BINARYDIR)/*
|
| |
blackwine
Registered: Jan 2013
Posts: 3 |
Spider, remove:
$(RM) $@
And try again. The problem is that you define your $(OBJECTS), but you remove them and pack them elsewhere. If you have some intermediate objects you can define them using e.g:
.INTERMEDIATE: loader-not-packed.prg rasters-not-packed.prg |
| |
spider-j
Registered: Oct 2004
Posts: 444 |
Thanks for the hint. Still I don't understand completely how to get it working like I want.
Gotta try out a few things... :-) |
| |
Mr. SID
Registered: Jan 2003
Posts: 421 |
Useful hint: running "make -d" outputs lots of debug information to help with problems like that... |
| |
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: 11108 |
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: 1055 |
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: 11108 |
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: 11108 |
seperate rule is just a convention from old GNU times i think, when it took quite a while :) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
At least GNU make will re-read rules when one of the makefiles changes -- not sure what other flavors of make do. |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
For people like me, with no formal computer science training, I am always very late to the party, picking up what's logical. Coded too long in a monitor, coded too long on the native platform, coded too long without realising the value of git.
I do sublime and Swoffas plugin for KickAssembler, and I use the make.bat that it supports. My general way of working is a "fix.asm" where I load files, patch them and then save them back.
So this:
.file [name="temp\raw.prg", allowOverlap=true, segments="themain,themainpatch"]
Do I need to rethink my structure? As I see the examples, they are still assuming that there is and -o output from the assembly phase and I simply don't have that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Just to say it once: Forget the advice about cygwin. These days please use msys2 - which is nicer in every aspect. |
| |
Krill
Registered: Apr 2002
Posts: |
Quoting Bacchusmake.bat I think batch files are out of scope of this thread. :) |
| |
Danzig
Registered: Jun 2002
Posts: 428 |
Quote:Just to say it once: Forget the advice about cygwin. These days please use msys2 - which is nicer in every aspect.
anyone tried that jizzle with WSL2 with, say, debian? should even work with starting WinVice on the desktop!? |
| |
Stone
Registered: Oct 2006
Posts: 168 |
Quote: Just to say it once: Forget the advice about cygwin. These days please use msys2 - which is nicer in every aspect.
Indeed. And stay away from the packages you can find with chocolatey. Both 'make' and 'grep' are compiled without support for wildcards/glob patterns... |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Quote: Indeed. And stay away from the packages you can find with chocolatey. Both 'make' and 'grep' are compiled without support for wildcards/glob patterns...
I would never ever install something called "chocolatey", no matter what it was. |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
@krill - of course. I am exploring moving away from bat files.
@groepaz - This is under Windows 11 and my shell has support for MAKE via the Embarcadero installation of Delphi I have. So MAKE work without any additional installation for me (I do have MSYS2 for building VICE as I presume you already know ;-)
The particular issue I had with segments in KickAssembler was solved. In the makefile define the address of where the patch is (so I can reuse that address for the calling address of the cruncher) and then the general build of the "import binary, patch and save a patched copy" is like this:
*=$0801
.segmentout [allowOverlap=true, segments="themain,themainpatch"]
.segment themain []
* = $0801
.import c64 "depacked/x.prg"
.segment themainpatch []
*=cmdLineVars.get("InsertCode").asNumber(16) |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quote: Quote:Just to say it once: Forget the advice about cygwin. These days please use msys2 - which is nicer in every aspect.
anyone tried that jizzle with WSL2 with, say, debian? should even work with starting WinVice on the desktop!?
Yes, running Vice on the Windows desktop using WSL2 works fine for me so far. I use Windows 11 with WSL2 and Ubuntu 20 as Linux distribution.
And for development you can use Visual Studio Code with the remote WSL extension, so you have the VS Code UI running on the Windows desktop and the VS Code Server and your command line tools running under Linux in WSL2. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Doesnt VS Code run in WSL2? |
| |
Danzig
Registered: Jun 2002
Posts: 428 |
Quote: Doesnt VS Code run in WSL2?
No, worse, Electron app alias Browser :-D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
*gets the garlic out* |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quote: Doesnt VS Code run in WSL2?
When running VS Code in WSL2 the VS Code server is running in WSL2, while the UI on the Windows desktop is the regular VS Code for Windows application acting as a client.
When running Vice in WSL2 the UI on the Windows desktop is an RDP session into the WSLg X/Wayland/Pulse Audio server.
 |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quote: When running VS Code in WSL2 the VS Code server is running in WSL2, while the UI on the Windows desktop is the regular VS Code for Windows application acting as a client.
When running Vice in WSL2 the UI on the Windows desktop is an RDP session into the WSLg X/Wayland/Pulse Audio server.
Is there any special reason for doing this kind of things instead of simply running GNU/Linux? Even in a VM if for some Very Important Reasons somebody cannot live w/o Windows on their machines? |
| |
Krill
Registered: Apr 2002
Posts: |
Quoting Silver Dream !Is there any special reason for doing this kind of things instead of simply running GNU/Linux? Even in a VM if for some Very Important Reasons somebody cannot live w/o Windows on their machines? Boggles the mind. Besides, native Windows builds of make and other relevant *NIX tools exist, as mentioned above. =) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting KrillBesides, native Windows builds of make and other relevant *NIX tools exist
Right. And not since yesterday either. I remember even in my (and Oliver's) "Universal Makefile" effort was put to make it compatible with native [GNU] make on Windows and it's been over a decade ago :-)
https://wiki.cc65.org/doku.php?id=cc65:project_setup |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
It also shows some of the horrors you encounter when dealing with make on cmd.exe :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quote: It also shows some of the horrors you encounter when dealing with make on cmd.exe :)
Hehe - might be. It was Oliver who insisted on (and tested) Windows / cmd.exe compatibility ;-) I wasn't against – why would I be? – but never had a chance to check and see what horrors lurk in there |
| |
Stone
Registered: Oct 2006
Posts: 168 |
Quote: I would never ever install something called "chocolatey", no matter what it was.
Good for you! However, some poor sod looking for answers on stackoverflow might be tempted to do so... |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Quote: Good for you! However, some poor sod looking for answers on stackoverflow might be tempted to do so...
Either that, or some Amiga nerd running OS 3.9 and cpu accelerator + dual CD-ROM burners in a bigtower setup. |
