Support powerpc

[barracuda156]

What does this PR do?

This PR adds initial support for PowerPC.

P. S. Could someone explain how to force the build system actually use the patches .lua sources? Currently the build somehow sabotages applied changes, whether I build in a standard way or via boostrap script. I can build a working executable for powerpc with no issues, but it still does not acknowledge ppc among supported archs.
From earlier PRs adding support for riscv and loongarch it follows that nothing else needs to be changed, and a search across codebase does not point to any other instances of arch definitions. Yet the build ignores whatever is added.

How does this PR change Premake's behavior?

It does not affect currently supported archs.

Did you check all the boxes?

• Focus on a single fix or feature; remove any unrelated formatting or code changes
• Add unit tests showing fix or feature works; all tests pass
• Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged)
• Follow our coding conventions
• Minimize the number of commits
• Align documentation to your changes

[nickclark2016]

Those changes just allow Premake to accept riscv and loongarch as architecture types. In order to push those changes throughout the system, the various exporters (i.e. gmake) and toolchains (gcc, clang) would need to have some of their internal maps updated to support ppc.

We can either add those changes onto this current PR, or you may want to follow them up in a future PR.

[nickclark2016]

This may be better being "ppc32" instead of "ppc", since it makes it sound (in my mind) like 32 bit is the default, when 64 bit is the default on almost all desktop and server class hardware these days.

[barracuda156]

Like with arm and mips, convention is just ppc. Though I won’t really object if there is a strong preference to do otherwise.

[nickclark2016]

Good enough reason for me. Let's leave it.

[barracuda156]

Those changes just allow Premake to accept riscv and loongarch as architecture types. In order to push those changes throughout the system, the various exporters (i.e. gmake) and toolchains (gcc, clang) would need to have some of their internal maps updated to support ppc.

We can either add those changes onto this current PR, or you may want to follow them up in a future PR.

After I build premake on a powerpc machine, running premake --help does not show ppc among archs, and trying to use it to build something for ppc returns an error of unsupported arch. It looks like the build somehow overrides the changes applied to the sources.

gcc on its own supports ppc/ppc64, of course, though maybe the sources here needs some modification as well.

[nickclark2016]

Those changes just allow Premake to accept riscv and loongarch as architecture types. In order to push those changes throughout the system, the various exporters (i.e. gmake) and toolchains (gcc, clang) would need to have some of their internal maps updated to support ppc.
We can either add those changes onto this current PR, or you may want to follow them up in a future PR.

After I build premake on a powerpc machine, running premake --help does not show ppc among archs, and trying to use it to build something for ppc returns an error of unsupported arch. It looks like the build somehow overrides the changes applied to the sources.

gcc on its own supports ppc/ppc64, of course, though maybe the sources here needs some modification as well.

Got it, misunderstood the issue. Just to make sure, when you're running premake, you're using the most recently build binary, correct?

[barracuda156]

Got it, misunderstood the issue. Just to make sure, when you're running premake, you're using the most recently build binary, correct?

Initially I just added patches into the existing portfile from MacPorts https://github.com/macports/macports-ports/blob/ecf89c2ff86a0b3be80dff99ffc8d09edd83fac5/devel/premake5/Portfile and ran the build. It uses gmake.macosx config. After finding out that while I can make the build to work, arch support is not being added, I thought that I need to go via bootstrap procedure, and modified the portfile to invoke instead make -f ./Bootstrap.mak osx with setting PLATFORM = ppc in the script. However that did not lead to the intended result either.

Maybe I am not doing it right. Is there a canonical procedure to bootstrap premake on a new platform? I.e. I start from only having the toolchain, but no existing premake5. (There is an old premake4 for ppc, but I am not sure it is usable for this purpose.)

[barracuda156]

@nickclark2016 Oh wait, I think I got it working. Give me a min to check.

[nickclark2016]

Got it, misunderstood the issue. Just to make sure, when you're running premake, you're using the most recently build binary, correct?

Initially I just added patches into the existing portfile from MacPorts https://github.com/macports/macports-ports/blob/ecf89c2ff86a0b3be80dff99ffc8d09edd83fac5/devel/premake5/Portfile and ran the build. It uses gmake.macosx config. After finding out that while I can make the build to work, arch support is not being added, I thought that I need to go via bootstrap procedure, and modified the portfile to invoke instead make -f ./Bootstrap.mak osx with setting PLATFORM = ppc in the script. However that did not lead to the intended result either.

Maybe I am not doing it right. Is there a canonical procedure to bootstrap premake on a new platform? I.e. I start from only having the toolchain, but no existing premake5. (There is an old premake4 for ppc, but I am not sure it is usable for this purpose.)

Please verify your build outside of the macports configuration. I am not familiar enough with that ecosystem to help you out on that specific piece of your pipeline. I'm not sure who manages the MacPorts configuration.

[tritao]

Nice one, btw after it's working, don't forget to add some docs in website/ folder.

[barracuda156]

@nickclark2016 @tritao Ok, I can confirm that I have not only building, but actually working premake5 on powerpc now. There is just one port in MacPorts which depends on premake5, and it was restricted to x86/arm, and now I can build it successfully.

For the arch support what is in this PR is sufficient. (I did not include universal for powerpc, just not to overload the code; if desired, it can be added as universal_ppc, but it can work only with Xcode gcc, since clang is broken for ppc, while modern gcc needs driverdriver to be implemented, and until that cannot accept multiple arch flags.)

To have premake5 working on macOS ppc specifically, there are three more issues to address:

1. Securetransport does not build on < 10.7, and curl should use alternative tls. Mbedtls works; since Unix makefile uses that, I used it as well. MacPorts curl by default uses openssl, but that is much heavier to build, of course.
2. Darwin < 16 does not have clock_gettime and friends. MacPorts (or pkgsrc) have legacy-support library with implementation of that, otherwise some fallback will be needed.
3. mbedtls needs -std=c99 or -std=gnu99 – this is trivially fixable.

This results in a working premake: macos-powerpc/powerpc-ports@1397056

I am not sure macOS-specific fixes are wanted, but PowerPC is worth supporting in any case, since both *BSD and Linux support it in their modern releases.

[barracuda156]

@Jarod42 Updated and rebased to master.

[nickclark2016]

Given you appear to have access to more legacy Apple hardware than I have, would you be willing to tackle issues 1 and 2 that you brought up? (TLS and clock issues)

[barracuda156]

Given you appear to have access to more legacy Apple hardware than I have, would you be willing to tackle issues 1 and 2 that you brought up? (TLS and clock issues)

I have a patch to use mbedtls (like it is done for Unix otherwise) here: macos-powerpc/powerpc-ports@1397056
But I do not know how to do it conditionally on macOS version (and what is a supposed threshold), and I guess there is no desire to switch all macOS to mbedtls?

For clock_gettime the easiest solution is just using legacy-support (which does not require MacPorts, since it has no dependencies, and it is used, I believe, by NetBSD folks with pkgsrc too).

[nickclark2016]

We have arguments in our build already for "system" vs vendored dependencies. We could probably just add an argument for explicit opt in to the Bootstrap.sh.