aamachine brew formula broken

Authoring Dialog
,
1

I’ve was just trying to bounce the aamachine and dialog homebrew formulas.

aamachine is broken:

==> Upgrading dialog-if/brew/aamachine
  0.5.1 -> 1.0.0
==> make
Last 15 lines from /Users/howard.lewisship/Library/Logs/Homebrew/aamachine/01.make.log:
gcc -Wall -O3 -DVERSION=\"1.0.0\" -DVER_MAJOR=1 -DVER_MINOR=0    mkheader.c   -o mkheader
/Library/Developer/CommandLineTools/usr/bin/make -C 6502
make: *** No rule to make target `6502/c64_crunched.bin', needed by `table_c64terp.h'.  Stop.
make: *** Waiting for unfinished jobs....
gcc -Wall -O2 -DVERSION=\"1.0.0\"    aambox6502.c fake6502.c   -o aambox6502
xa -o aambox_frontend.bin aambox_frontend.s
make[1]: xa: No such file or directory
gcc -Wall -O2 -DVERSION=\"1.0.0\"    mkfont.c   -o mkfont
xa -o decruncher.bin decruncher.s
make[1]: xa: No such file or directory
gcc -Wall -O2 -DVERSION=\"1.0.0\"    cruncher.c   -o cruncher
make[1]: *** [aambox_frontend.bin] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [decruncher.bin] Error 1
make: *** [6502] Error 2

If reporting this issue please do so to (not Homebrew/* repositories):
  dialog-if/brew

I’ll revert it … is it ok for dialog to rely on aamachine 0.5.1 for the meantime?

2

Ahh, right, it’ll need the xa65 assembler now.

When building aambundle, the process goes:

engine.s → xa → c64_crunched.bin → gcc → aambundle

Linus distributed all three of engine.s, c64_crunched.bin, and aambundle, and he set up the build process so that running xa is fully optional—it’s not part of the normal Makefile. But when I was first working with this, I found it so unintuitive I’d even call it a trap for users. By default, rebuilding aambundle will not incorporate any changes to engine.s, since rebuilding c64_crunched.bin is an entirely separate process.

So when I was setting up the community version, I didn’t include c64_crunched.bin in the distribution. In my opinion, if you’re building from source, that should include assembling engine.s as part of the process; and if you’re not building from source, you’ll just use the included aambundle executable.

The upshot is, if you want homebrew to build aambundle from source, it’ll either need xa65 as a dependency, or you’ll need to provide the .bin files in the distribution. But the official release also includes aambundle binaries for Windows, Mac, and Linux, so on most configurations I think those should be fine.

1 Like
3

For this, afraid not. Dialog 1b/01 specifically emits Å-machine 1.0 bytecode, with some opcodes added, some removed, and some changed from 0.5. The 0.5 interpreters won’t run it.

4

I’ll look into the formula, if the .zip file contains pre-built binaries, then I can adjust the formula instead of running a make; I didn’t write the initial formula.

5

I’ve updated the Formula to use the pre-built binaries.

However, there’s only pre-built binaries for ARM (not Intel).

Ideally, aamachine build should cross-compile osx-intel binaries as well?

1 Like
6

Looks like the aamachine tools don’t run on OS X Intel.

However, the dialog tools (dialogc, dgdebug) do run on Intel even though they are packaged into a macos-arm64 directory. I suspect there’s some optional cross-compilation flag that could perhaps be used when building aamachine binaries?

7

Hmmm. For aamrun specifically, I needed to choose “macos-arm64” or “macos-x86” when compiling, and I took a stab in the dark there; I can also do it the other way. (That one’s cross-compiled on a Linux machine.) For aambundle and aamshow, though, they’re built on a Mac via Github actions, exactly the same as dialogc and dgdebug are. I don’t know why those don’t work if dialogc and dgdebug do.

8

I get the error “Bad CPU type in executable.”

9

Very strange…this is the action that builds dialogc and dgdebug:

  build-macos:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - name: install dependencies
        run: |
          brew update
          brew install frotz diffutils
      - name: get the Å-machine interpreter
        run: git clone https://github.com/Dialog-IF/aamachine.git
      - name: make
        run: make --directory=./src
      - name: make test
        run: make test
      - uses: actions/upload-artifact@v4
        with:
          name: macos-arm64
          path: |
            src/dgdebug
            src/dialogc

And this is the action that builds aambundle and aamshow (with the aamrun part removed):

  build-macos:
    runs-on: macos-latest
    steps:
    - uses: actions/checkout@v4
    - name: install dependencies
      run: |
        brew update
        brew install xa
    - name: make (blobs)
      run: make --directory=./src/6502 aambox_frontend.bin c64_crunched.bin c64_drivecode.bin c64_loader.prg
    - name: make (mac)
      run: make --directory=./src aamshow aambundle
    - uses: actions/upload-artifact@v4
      with:
        name: macos-arm64
        path: |
          src/aamshow
          src/aambundle

I’m not the most experienced with Github actions, but I don’t see any important difference between these.

Looking at the Makefile for dgdebug:

CC		= gcc

dgdebug:		debugger.o frontend.o report.o arena.o ast.o parse.o compile.o eval.o term_tty.o accesspred.o output.o unicode.o fs_tty.o
			${CC} ${LDFLAGS} -o $@ $^ ${LDLIBS}

And for aamshow:

CC		= gcc

aamshow: aamshow.c crc32.c aavm.c aavm.h crc32.h
	${CC} ${CFLAGS} -o $@ aamshow.c crc32.c aavm.c

I guess the difference is that dgdebug makes intermediate .o files first and then links them together, while aamshow doesn’t? I don’t know how that would affect this, though…

10

One random guess: a difference in the linked libraries.

11

I had Claude figure out how to do this:

It should now build universal binaries, though I haven’t verified that these actually work – but Claude seemed confident.

1 Like
12

Probably could have kept the old Formula working with a local build by adding a Homebrew dependency on the xa tool … but just extracting pre-built universal binaries is better for everyone.

13

I know nothing about how Homebrew formulas are set up, so whatever you think works best for users, let’s go with that!

14

It’s small enough that the extra size of universal binaries shouldn’t matter for anyone.

15

Does Claude ever seem any other way? :slight_smile:

1 Like
16

Yeah, aamrun is going to be much bigger than the rest just by its nature, but it’s also not needed for much of anything except working on the Dialog compiler. The rest are all written in pure C.

17

I can take care of the formula; it’s pretty easy at this point. Just need a 1.0.1 release.

18

You should have enough permissions to make a release; just add a note to readme.txt, update the version numbers everywhere (version_numbers.txt says where to look for that), then make a new release tagged release-1.0.1 on Github.

(I can also do it if you prefer, but I’m trying to get the bus number for this project as high as possible.)

19

I’d recommend making it a PR for the version number updates, so people can chime in if they object to the release, but I don’t foresee any real problems here (it’s nothing compatibility-breaking) so we’ll approve it right away.

20

Ok, I’ll take care of it, maybe tonight after work.

1 Like