Build system is not great

[chrisridd]

I'm trying to build on macOS, and it is rather frustrating to say the least. It'd be nice to just run 'make' at the top level and for it to do the "right thing". The freemint make system seems pretty good and generally does good things, for example.

It isn't obvious there is a "wrong" version of freetype. I've raised a separate issue for that.

Building with gcc 10 fails in bitplane/spec.c. The following diff seems to fix it correctly (the same ifdef is used in the code using screenpt).

diff --git a/fvdi/drivers/bitplane/spec.c b/fvdi/drivers/bitplane/spec.c
index ff92fcf..7f3e231 100644
--- a/fvdi/drivers/bitplane/spec.c
+++ b/fvdi/drivers/bitplane/spec.c
@@ -134,8 +134,10 @@ long check_token(char *token, const char **ptr)
  */
 long initialize(Virtual *vwk)
 {
+#ifdef __mcoldfire__
     /* use screenpt system variable on Firebee as Physbase() doesn't work there (see below FIXME) */
     short** screenpt = (short **) 0x45e;
+#endif
     Workstation *wk;
 #ifdef FAST
     char *buf;

Even though I'm setting CPU=000 it tries to build some v4e stuff (firebee?)

There is a dependency on a Linux x86 binary - pacf - for at least one driver. It'd be nice to make that bit optional somehow, or perhaps to check in whatever pacf produces?

[mfro0]

pacf is indeed a binary from Micro APL's portasm package (https://microapl.com/Porting/PortAsm.html, unfortunately not available for Mac OS) meant to translate m68k assembly into ColdFire compatible source files.

Anyway, this shouldn't be called if CPU is set to ' 000' - and it isn't - for me:

make CPU=000 

compiles fine for me (on Linux, Mac OS as well) using m68k-atari-mint-gcc 4.6.4 even without a local pacf installation. How are you calling make?

[chrisridd]

I must have been overthinking it somehow, perhaps fooled by the buildit.sh script.

I can confirm, make CPU=000 and make CPU=020 (etc) work fine on my Mac.

Apologies for the issue spam!