I noticed the latest Mac version listed is 1.01 so I downloaded 1.04 and it built just fine out of the box, compiles the demo.asm and the resulting SSD works perfectly.

Am I missing a trick or is there no version > 1.01 because, well, it's THAT easy so no-one's bothered?

I've then gone on to create an XCode project for it pulled the source in and set it up to build a 32Bit Universal binary for 10.4 and above.

As long as I'm not missing anything obvious here (not being a beebasm user yet), I'd be happy to upload it to the Wiki. In fact, it's perfectly possible to be a bit cleaner than that and just include the Mac version in with the Windows version since if you build it using the XCode project then it won't use the Makefile and thus they could all happily coincide as far as I know (I can test that).

I've not tested the universal binary on a PPC machine yet but I can tomorrow night.

Martin.

Actually, it makes sense to attach the version here for testing just in case I don't get round to it.

I've packaged up the 1.04 mac universal binary version together with the current 1.04 windows version and an XCode project that is very little more than a wrapper for building the project. It's about the quickest, easiest (or maybe dirtiest?) way of achieving a universal build. I wouldn't have a clue where to start with manually configuring the Makefile to do the same thing.

Tested:
demo.asm under i386, 10.6.3
relocdemo.asm under i386, 10.6.3

Could do with testing both demos under ppc 10.4.x or 10.5.x and maybe an i386 10.4.x or 10.5.x

I can test the ppc 10.5.x combination but I can't do any other intel tests as all my macs are on the latest OS versions.

Martin.

Yep, that's exactly the reason BeebAsm was always designed to be absolutely as portable as possible, so in theory new releases should just compile without trouble.

In my opinion, it'd be best to include all the build environments (project files for XCode, VS2008 etc) in the one package, preferably in some subdirectory somewhere, but I don't have any time to organise this in the code at the moment.

There is already a Mercurial repository set up for BeebAsm - feel free to become a registered user and commit any improvements you make. Not quite sure how this works, but perhaps samwise will be along in a moment with the keys to the repository

Hi Rich,

I PM'd Sam shortly before knocking it on the head for the night and he reminded me about the repo which I confess to having completely forgotten about!

I cloned it locally and added my 'change' to it (locally). The result is actually the addition of a whole ONE file (!), which is actually a directory that on the Mac appears as a file. The rest are per user settings and therefore should be ignored by Hg anyway.

I have all of the standard XCode and Visual Studio type stuff in a global .hgignore file in my user directory so that's all taken care of. The only other thing that I did in my local clone was to add an ignore file to the repository itself to ignore the two output files "beebasm" and "beebasm.exe" since they shouldn't really be versioned unless they really, really are a pig to rebuild (which they're not in this case) as they're binary.

I guess though that's up for discussion as it may be easier to encourage testing from the repository if they are in there?

Currently the "beebasm.xcodeproj" folder is in the 'src' directory but it's no trouble to put it in it's own directory if that makes more sense?

If you're at the VCF at the weekend then we can chat about it then, if not I guess I can just get on and do it, or talk about it here

When we're happy, all I need is for Sam to give my forum account push access and I can push my local changes up.

Martin.
[EDIT] Ok, you're in Mallorca, so I doubt coming to the VCF

Guys,

We're breaking new ground here with BeebASM (as the first cross-platform RS project) so we probably just need to come to some conclusions about how best to organise the project.

My thought is that we should try and follow in the footsteps of other successful, cross-platform projects which manage to consistently keep their projects working across multiple platforms. The main one I have in my head is ScummVM which seems to do a very good job of managing this. Other examples might include some of the older versions of the Inform language. I'm sure you can think of other examples.

I noticed a very interesting topic here actually, tho it covers GUIs more than we probably need to be worried about. Worth a quick read, tho.

Anyway, it's a bit late to say much now - I'll have a chinwag with Martin (and anyone else who wants to get in on this, can join us) about it this weekend, and then we can thrash it out with Rich on the forums when we get back. I'm currently thinking we basically need to agree on a cross-platform-friendly way of laying out the project and then if I stepped up to be the Linux release manager and Martin did the Mac, then Rich could mail us before each release and we could try doing simultaneous releases for all three? Maybe even find someone to do a regular RISC OS build too.

Martin has pointed out that neither he or I really use or understand BeebASM as much as would be preferable to be release managers, but I'm not sure that should stop us helping out - I figure we just go back to Rich, if we uncover any issues, so they can be looked at before the actual release.

Potentially, perhaps Rich or someone else could also create a test beebasm project for us too that we can run through to ensure the builds are working?

Dunno. All ideas just floating in my head.

Rich, if you have any thoughts, feel free to post or PM them to me and me and Martin can chat about them. I'll endeavour to write up our discussions and post when we get back!

Sam.

I've had a bit more of a ponder on this today and certainly at the moment it probably makes more sense just to add a bit of modification to the Makefile. I'll have a play a bit more tonight. I worked out how to modify the makefile to get the universal binary out but it's putting the object files in the wrong place now and thus not cleaning up properly when you 'make clean'.

Since I was only using the XCode project to do the 'universal' bit for me I can probably junk the XCode project now. I don't really see BeebAsm ending up with much in the way of OS specific code if it doesn't have any already so an XCode project is probably not really worth it.

On a more general note though, the executable I built last night works perfectly on my G4 Mac Mini, so that's a successful test of PPC on 10.5.x (whatever the latest is - it updated itself tonight).

I also tested on my work laptop earlier too which is Intel 10.6.4, again updated yesterday.

The Makefile should work exactly the same on the Mac as on the PC, namely it should create a directory src/objects into which object and dependency files are put, and it should output the executable in the parent directory. I don't know what you mean by a 'universal binary' (sounds like an Apple-centric thing), but I'd expect gcc to be able to output one of these without problems - I'd imagine that the .exe file extension isn't appropriate for the Mac, but this can easily be changed in the Makefile.

One question is if there is some environment variable which the Makefile can check to determine which platform it's running on? If not, I guess it can be passed on the make command line, and Makefile.inc modified to require that this variable exists.

Regarding IDE project files, I think it's perfectly reasonable to bundle .xcodeproj and .vcproj files in the package, as they provide a quick and simple way of getting the project compilable on the platform of your choice (and plenty of people like working in IDEs).

I can't imagine any of the source code requiring anything platform-specific - unless you want to do wacky filesystem related stuff (for example, reading the current working directory, which I don't think can be done portably in C++).

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.

I'm no fan of Makefiles either but I admit the makefile solution sounds the best

Well, apart from briefly chatting to you and Sam, I more or less entirely forgot to talk to anyone about this in any depth! I intended to ask which of the bits that I've mentioned in the makefile work 'out of the box' on both linux and RiscOS. I can work out the linux stuff myself soon enough. Hmm, actually, I may be able to with RiscOS. Depends which version of RiscOS it builds on. Bearing in mind I don't even have delivery of my 3010 yet, let alone worked out how to boot it up and use it, RiscOS is better left to someone else!

We're off on holiday for a few days so I've still not done a branch and upload but I'll get to it by the weekend. Then it can be reviewed and merged.

I feel that's probably the best way at the moment on a project such as this where I'm really not adding very much, just a small fraction of ease of use stuff