obc: Portfile and patch for Oxford Oberon 2 compiler

[jking+macports@…]

Attached is a Portfile and single patch for the Oxford Oberon 2 compiler (obc).

[ryandesign (Ryan Carsten Schmidt)]

Thanks.

[ryandesign (Ryan Carsten Schmidt)]

Why version 2.8.3? 2.8.4 is out since February.

What is the reason for the line "configure.build_arch i386"? Are you trying to prevent building on PowerPC machines, or on 64-bit machines? Currently this prevents both. I assume you meant the latter, since I do see a segmentation fault when trying to build for x86_64 on Snow Leopard, which goes away when I use i386. Either way, the correct way is to use "supported_archs", not set configure.build_arch directly.

I'm surprised that /opt/local/lib/obc/obb1 and /opt/local/lib/obc/obc1 are still ending up built for x86_64, not i386. Is that how it's supposed to be?

I'll remove "--prefix=/opt/local" from the configure.args. Hardcoding /opt/local is not ok, and MacPorts already puts "--prefix=${prefix}" in configure.pre_args.

[jking+macports@…]

My apologies. Their wiki still links to 2.8.3 as the latest version for generic Unix.

Indeed, the compiler only works on 32-bit Intel systems; a 64-bit compiler generates invalid code. Having obb and obc1 generated for x86_64 is an artifact of the build process and works okay.

Also, my apologies on the --prefix=/opt/local thing. That was left in during debugging when I was testing the DESTDIR patch.

I have attached a new Portfile and patchfile. Thanks.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jking+macports@…:

Indeed, the compiler only works on 32-bit Intel systems; a 64-bit compiler generates invalid code.

And what about on PowerPC? I was able to compile the port on a Power Mac G4, but I don't know if the software works.

[jking+macports@…]

Unfortunately, I don't have access to a PPC system to test it on, so I don't know either. Given the compilation notes at ​here I don't think it will work (quotes like "Set up to use the 10.5 toolkit and generate i386 code by cp macport/jhbuild-custom ~/.jhbuild-custom. (Some things don't work in 64 bits yet." and "Set the compiler for 32 bits with configure CC='gcc -arch i386'.").

[ryandesign (Ryan Carsten Schmidt)]

Those note seem to be for the specific case of compiling a Leopard-compatible version of obc while running Snow Leopard. Certainly in that case you would need to specify 32-bit arch flags, because Snow Leopard builds 64-bit by default. I don't see any indication there that obc is expected not to work on PowerPC, so I won't make that assumption. I committed the port in r74141, adding the standard modeline, and changing supported_archs to "i386 ppc". If someone notices PowerPC problems I'm sure they'll file a ticket. Thanks for the port!

[mike@…]

Much confusion has resulted from a failure to contact the original author of the software. This port is based on release 2.8, obsolete now that 2.9 is out with significant bugfixes. Please get in touch before releasing a new port! -- Mike Spivey

[jking+macports@…]

Professor Spivey, thank you for your comments via out-of-band email; I've taken them to heart.

I've attached a new portfile that includes a check for architecture to selectively enable the JIT code. I've also updated the portfile to build the latest revision of the compiler. I've attached a patch to the portfile to this ticket, along with an updated patch-destdir.diff file.

[jking+macports@…]

Updated version for 2.9.0 to correct DESTDIR

[ryandesign (Ryan Carsten Schmidt)]

In the conditional, I think we should check ${configure.build_arch} instead of ${os.arch}. Also, I think there's a problem with the line "configure.args-delete --disable-jit" since "--disable-jit" isn't in the configure.args to begin with so there's nothing to delete. Did you mean "configure.args-append --disable-jit"?

In the future, we should do port updates in new tickets, not reusing existing resolved ones.

[jking+macports@…]

Thank you Ryan; I've updated the Portfile to reflect your changes. My apologies; I'm not super-familiar with the Portfile format just yet.

[ryandesign (Ryan Carsten Schmidt)]

possible patch

[ryandesign (Ryan Carsten Schmidt)]

I still don't think the conditional is what you want. The way you have it in your latest patch, you're saying that we should use --disable-jit on i386, otherwise don't. Isn't that exactly the opposite of what we want? According to the developer, the just-in-time compiler only works on i386, so we should use --disable-jit unless we're building for i386, in which case we want to remove --disable-jit so that JIT is used.

But I wonder if we ever need the --disable-jit argument at all. It built fine for me on both i386 and ppc if I didn't specify that option. I assume the software would enable JIT if possible, and leave it off if not. If that's so, then we can simply do this​, can't we?

[jking+macports@…]

Sheesh, I'm sorry. My only excuse is that it's finals week. In my communication with Professor Spivey, he recommended that the JIT be explicitly disabled on non-i386 platforms. However, if you are able to correctly build the code on PPC then I think using your patch file is fine. Sorry again for the confusion.

[mike@…]

The configure script attempts to recognise the host architecture, and enables the JIT if the architecture is one of the ones supported, from this short list: [x86]. So it shouldn't be necessary to specify --disable-jit, whatever the architecture.

If building on an x86-64 machine, the C components (i.e. the runtime system) need to be built in 32-bit. It doesn't matter whether the OCaml components (i.e. the Oberon compiler) are built with the 32-bit or the 64-bit OCaml compiler. I don't know much about MacPorts, so I don't know how accurately you can specify that requirement.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mike@…:

The configure script attempts to recognise the host architecture, and enables the JIT if the architecture is one of the ones supported, from this short list: [x86].

When you say x86, you mean i386? The possible architectures in MacPorts are i386, x86_64, ppc, and ppc64.

So it shouldn't be necessary to specify --disable-jit, whatever the architecture.

Ok, I commited my patch in r74441.

If building on an x86-64 machine, the C components (i.e. the runtime system) need to be built in 32-bit. It doesn't matter whether the OCaml components (i.e. the Oberon compiler) are built with the 32-bit or the 64-bit OCaml compiler. I don't know much about MacPorts, so I don't know how accurately you can specify that requirement.

I believe we already specify that. We say "supported_archs i386 ppc" meaning that MacPorts will pass "-arch i386" (or "-arch ppc") in the CFLAGS, CXXFLAGS and LDFLAGS when building obc. MacPorts will enforce this architecture for all dependencies as well, except that we also write "depends_skip_archcheck ocaml" so that MacPorts does not attempt to enforce any particular architecture of ocaml.

[mike@…]

Replying to ryandesign@…:

When you say x86, you mean i386? The possible architectures in MacPorts are i386, x86_64, ppc, and ppc64.

Yes, i386: although in practice that really means that the code suits processors that >= i486, and wouldn't work on the original 80386/80387. Since there aren't any macs that are < Pentium, it's a moot point that appeals only to avid readers of the Intel architecture manuals.

If building on an x86-64 machine, the C components (i.e. the runtime system) need to be built in 32-bit. It doesn't matter whether the OCaml components (i.e. the Oberon compiler) are built with the 32-bit or the 64-bit OCaml compiler. I don't know much about MacPorts, so I don't know how accurately you can specify that requirement.

I believe we already specify that. We say "supported_archs i386 ppc" meaning that MacPorts will pass "-arch i386" (or "-arch ppc") in the CFLAGS, CXXFLAGS and LDFLAGS when building obc. MacPorts will enforce this architecture for all dependencies as well, except that we also write "depends_skip_archcheck ocaml" so that MacPorts does not attempt to enforce any particular architecture of ocaml.

Sounds good to me.