Add support for CYGWIN.

[carlo-bramini]

What does this PR do?

This PR adds support for CYGWIN.
After these few fixes, premake can be compiled and used for this new platform.

How does this PR change Premake's behavior?

These changes won't affect support for existing plaftorms and targets.

During my debug, I discovered that into src/base/os.lua there was a tiny mistake because it was adding "/usr/lib64/" instead of "/usr/lib64" (note the final "/" at the end of the string), so I fixed it. However, this is a minimal and safe fix, as you can see.

Anything else we should know?

CYGWIN follows much more BSD than Linux.
This allows to avoid duplications of code into the makefile.
So, once you get the sources fixed by this PR, you can build premake for CYGWIN by using this command:

make -f Bootstrap.mak bsd

After that, you will find the executable of premake under the bin/release directory.
The new port also passed all tests successfully.

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

You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to requests like these!

[nickclark2016]

I am not a fan of changing our vendored libs outside of updating them. Are these libraries buildable with Cygwin itself? If so, let's figure out why we can't build them in Premake (or if we just need to update our versions). If not, they will break again when we inevitably update our libraries.

[carlo-bramini]

Thank you very much for your reply.

I gave a look to the sources of cURL and it seems to me that this library has been already modified.
Its version claims to be 8.11.0 but the official source archive differs from the one included into premake.
The official source archive has not a config-linux.h header file and the one provided into the /contrib directory says that it has been automatically generated by CMake and modified by hand.
Same thing has been done for other config header files.
So, here I didn't worried to much when I did the fixes provided by this PR.
Perhaps, it would be worth to define HAVE_CONFIG_H somewhere and then add a curl_config.h instead.
So, you will include it with your changes and it will stay as it is even when upgrading the library, unless the entries into the config headers need to be updated too.
On CYGWIN, yes, cURL builds fines but it uses a curl_config.h generated by autoconf actually.

LUA also needed a fix.
Unfortunately, I had to do it into luaconf.h and it is not included into the official library, at least not yet.
The fix comes from the patch of the official LUA package for CYGWIN.
Infact, the build script for CYGWIN applies that patch before creating the binary package.
That fix looks correct to me, but probably the author never contributed it to the authors of LUA.

These two fixes seem to be the only ones outside the sources of premake.
If it is a problem, it would be nice if you could apply the PR even without the changes to cURL and LUA.

BTW, is it possibile to build premake without using the built-in libraries?
I have not understood how to do it and if it's possible, but using system libraries will solve the problems at roots.

[nickclark2016]

We definitely have made some minor changes, but we try to really keep them to an absolute minimum. We know stuff will break as soon as we try to update the libraries, and it's something I'm worried about. As for how to use system libraries, take a look at the build CI.

[carlo-bramini]

Just for information, I contributed a patch to LUA for supporting CYGWIN:

https://groups.google.com/g/lua-l/c/8-ZBF5pW6cA

Now let's hope that it will be included soon into the next release.