Ok, well I managed to get this all working last night using the Makefile. But...
A universal binary is indeed a Mac thing. It's their way of getting round the fact that they changed from PowerPC chips to Intel chips. It's essentially two executables in a single file. Some people refer to it as a 'fat binary'. You can also go the whole hog and have 32 and 64 bit versions as well so essentially up to 4 executables in a single executable. Means that one file works natively on both powerpc macs and intel macs. Saves multiple builds and downloads.
And this is where it get's complicated. The main area of problem is in the dependency generation. When specifying multiple architectures to gcc you can't use any of the 'M' flags so I had to separate a fair chunk of the 'dep' commands out to a variable and wrap it in a conditional according to defined OS. Not a biggie to be fair. In the end, I went with not generating dependency information on macosx. The project still compiles and runs just fine.
It also needs different CFLAGS, CXXFLAGS and LDFLAGS for 'macosx'. Then there's a different TARGET definition (without '.exe' on the end of the binary name) and a different path separator in the arguments to the run build phase. All stuff that is platform specific.
You can define the OS on the command line and pass it in, or simply have a commented section at the top of the makefile with defines for windows, macosx and other (linux, riscos and anything else that works out of the box but doesn't want the '.exe' extension). The builder then uncomments the desired one, or adds more if they want to support a new OS. I went for the latter.
Theres not many changes to 'Makefile', most of it is done in 'Makefile.inc' so a slightly different approach would be to have multiple include files (Makefile.macos, Makefile.linux etc.) and conditionally include whichever is required. That might keep the Makefile.inc's tidier.
I can chat to Samwise about the linux build and hopefully someone will be around to chat about the riscos build. I have a Kubuntu partition but it got late by the time I'd got it working last night.
Bottom line is, when I get back from VCF I'll create a couple of branches, one with it done the Makefile way, another with it done the IDE way. You can review and see which direction you prefer and I can merge in the one you choose and delete the others.
My personal preference now is for the Makefile. It feels tidier and also and IDE feels unnecessary since there's no GUI element to the program (yes, I know, irrelevant, it just 'feels' that way).
Oh, I also spent rather longer than I care to admit chasing my tail on why the build wasn't happening in the correct order. In the end I realised that I had an alias for the make command defined in my bash environment. I had 'make -j 5' defined which was conflicting with the '-j 1' in the makefile when "sub makes" were getting spawned. When I removed the alias things happened as they should. DOH!
Wow, that was a lot of writing 
Martin.
|
BeebASM-v1.04-WinMac.zip [397.15 KiB]
BeebAsm was always designed to be absolutely as portable as possible, so in theory new releases should just compile without trouble.