Port Premake to Cosmopolitan Libc

[tritao]

What does this PR do?

Decided to have a little bit of fun tonight and try to port Premake to https://justine.lol/cosmopolitan/index.html

It outputs a single binary that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS on AMD64 and ARM64. Premake at BIOS time anyone? 😆

It was relatively painless and all tests are passing besides the binary module test.

It might be possible to support these with cosmos_dlopen, but doesn't seem worth it to spend time on it.

I think this would be most valuable for those who want to bundle a Premake binary with their code as a single binary is needed on Git.

Anything else we should know?

Seems like it would be worth to support this as the changes are pretty minor and maintenance going forward should be minimal, but let me know if you have other thoughts.

If it seems like it would be worth, I can probably add it to the CI build.

[samsinsane]

I'm not necessarily opposed to this support, but in context of this project moving forward, this may not be viable for Premake to use. The lack of support for binary modules is concerning.

There has been a number of users who have been wanting Premake to stop using the contrib folder as-is. Some just want them to be the latest version available at the time of building, while others want them to be the system library. I think some also want them to be shared libraries so they can update/patch them.

Adding it the CI is fine, but I would be hesitant to make it one of the builds we ship in releases.

[tritao]

I'm not necessarily opposed to this support, but in context of this project moving forward, this may not be viable for Premake to use. The lack of support for binary modules is concerning.

Would be interesting to know how many users actually use binary modules. I would assume not too many. Either way doesn't seem too concerning to me to be a single limitation on this since binary module users probably already build binary modules for many platforms so the single binary would not be as useful.

There has been a number of users who have been wanting Premake to stop using the contrib folder as-is. Some just want them to be the latest version available at the time of building, while others want them to be the system library. I think some also want them to be shared libraries so they can update/patch them.

Ok, I think that's not an issue. If your concern is the custom changes to the contrib folder, then from what I can tell all those config changes are already non custom. I haven't been able to find them in upstream, even older version from the same time as Premake bundled version: https://github.com/curl/curl/blob/9506d01ee50d5908138ebad0fd9fbd39b66bd64d/lib/curl_setup.h

So I think the same problem will have to be fixed for all platforms, best approach seems to be defining HAVE_CONFIG_H and generating a curl_config.h based on config-*.h files stored in the repo at generation time.

I'll leave this as a draft for now, until I can add it to CI.

[samsinsane]

@tritao I should have been clearer in my points, sorry about that. My concerns are from the perspective of this being the only binary we offer, or even one of the binaries we offer. If this is something users have to go out of their way to build, then the extent of my concern is "I'd like to have feature parity, if it's an option".

I'm happy to see this merged in once the CI stuff is sorted.

[Jarod42]

gmake is the "deprecated" generator, in favor to gmake2

[tritao]

Do you know what's missing to unify both generators?

[tritao]

I have put a bit more work into this and everything is "ready", except I am getting a CI-specific http error which I cannot repro locally 😭

[samsinsane]

I have put a bit more work into this and everything is "ready", except I am getting a CI-specific http error which I cannot repro locally 😭

Are you testing with Ubuntu 22.04 as well? If so, then maybe just add into the error message in http_get.c:45 the URL, might be easiest to get it back from the curl object - should be curl_easy_getinfo with CURLINFO_EFFECTIVE_URL.

[samsinsane]

Oh, the HTTP tests require you to explicitly test everything. premake5 test --test-all

[tritao]

Oh, the HTTP tests require you to explicitly test everything. premake5 test --test-all

It's always something pretty stupid 😆

Ok, this is now working, but needed an upgrade to curl: #2280

Will take that commit out of this one once its merged.

[tritao]

This is now rebased and should be ready for review, latest version also fixes the previously misleading implementation of os.getversion as it was reporting the toolchain version instead of the OS version.

@tritao I should have been clearer in my points, sorry about that. My concerns are from the perspective of this being the only binary we offer, or even one of the binaries we offer. If this is something users have to go out of their way to build, then the extent of my concern is "I'd like to have feature parity, if it's an option".

Just to give my perspective on this, it was never my intention to offer this as the only build, but I think of it more of as experimental build for people to play with. I think it will be useful but if for some reason it doesn't turn out to be the case or becomes some sort of maintenance nuisance then I can understand if it gets removed in the future.