Migrate to premake5

[Itms]

We're currently using a modified version of premake4 to create our workspaces.

Premake5 is ​currently being developed and should reach a stable state soon, so we should try to start a soft migration by experimentally using their alphas along with our current version, and drop the latter when they release premake5.

Doing so will allow us:

• to generate project files for VS 2015, which we cannot use right now.
• to stop using a modified premake (see #1518), because premake5 allows us to create custom modules, which is a much more maintainable solution.

NB: They moved from BitBucket to GitHub so most of the links in the other ticket are broken, and I think one pull request vanished.

What has to be done:

• Change a bunch of things (really a no-brainer, took me 10 minutes) as explained here: ​https://github.com/premake/premake-core/wiki/Migrating-From-4.x
• Rewrite our customizations as a module (it's the big awesome change in premake5) as explained here: ​https://github.com/premake/premake-core/wiki/Extending-Premake
• If some of our fixes are not yet included and are still needed (read: if regressions appear), rewrite the fixes and make a pull request while they're in alpha and active
• If time permits: take a look at the new features and see if we can use them to improve our scripts (​https://github.com/premake/premake-core/wiki/What's-New-in-5.0); also see if our TODO/FIXME are still relevant

I tried to give it a go but I am not fluent in Lua and don't know much about all of this building stuff. The module system seems powerful and well documented, so maybe it will be really easy for people working on it before (CCing Yves and leper) to write those modules.

[Zsolt Dollenstein]

7zipped patch works on windows with vs2013 and premake5.0.0-alpha7

[Zsolt Dollenstein]

I took a stab at this and have a working version with the latest unmodified release of premake5 alpha7. I only tested this on windows10 with VS2013, other platforms will soon follow. I'm uploading this in case someone else wants to play with it.

Other than applying the patch, you need to download ​premake5 and put the binary into the build/premake folder.

Of the customizations we had for premake4:

• we apparently didn't use nasm support
• precompiled headers work smarter in premake5
• support for cxxtest was missing, so I wrote a premake5 module for it, that's also included in the patch

[leper]

Any chance to get that as a plain diff?

For this ticket as a whole maybe #1104 could also be considered.

[Zsolt Dollenstein]

I tried uploading the whole patch but it's 8MB and there's a 2MB limit on uploads :) Here's a diff with --no-diff-deleted that's smaller.

[Zsolt Dollenstein]

As for #1104, I don't understand the benefits of using CMake vs premake at this point. The original ticket points out that CMake supports XCode, but that's not a problem for premake either.

[fabio]

It would be nice to eventually be able to use a system premake, useful on Linux which can already provide a premake5 package.

[historic_bruno]

Replying to zsol:

As for #1104, I don't understand the benefits of using CMake vs premake at this point. The original ticket points out that CMake supports XCode, but that's not a problem for premake either.

I haven't used Premake5 yet, but based on 4.x, I would say CMake is more stable, has a larger community of testers and users, supports more platforms "out of the box", and has more built-in options. Premake's advantage is using Lua instead of the yucky scripts that CMake uses, but you end up having to write more logic to make up for what Premake lacks. Actually, I think newer IDEs come along more frequently than functional changes to our build system (our Premake version doesn't support clang, Xcode 4+, VS 2015 - to name a few).

As a practical example, I'm building primarily *nix-oriented libraries with CMake in Visual Studio 2013, there's even an option that lets me set the platform toolset to v120_xp, but I could just as easily build them for 2015, 2012, 2010, 2008, or something older (or newer). That's just scratching the surface of the options available. The library devs don't have to write all those cases into their build system, they just have to support MSVC.

At this point, I wouldn't want to switch, because there are so many nuances of our build system and it would be painful to convert them to CMake and test that everything still works on every platform. It sure would be nice to not have to majorly overhaul our build scripts every time we want to support a new IDE...

[Itms]

Hi zsol, I took a look at what you did, I have two questions:

• How come we didn't use nasm support? That surprises me a lot, are you sure of that?
• It would be nice to reimplement NoDebugHeap as a module, did you look into it?

Apart from that (and the way you presented the changes which is awful :p) I think this looks good and I will look into it when you answer the questions above!

Thanks for working on that.

[Yves]

Replying to Itms:

• How come we didn't use nasm support? That surprises me a lot, are you sure of that?

We stopped using it around 7 years ago. It had been used with Premake 3, so I added some custom code to support it with Premake 4 too when I upgraded. Then shortly after the upgrade, someone removed the remaining uses of nasm.

[Itms]

Ok, thanks for the information!

[Itms]

Update: we don't need premake5 right now, as long as we stick to VS2013. VS2015, whatever the premake, doesn't work well with SM31 so we should wait for #3708 before doing anything here.

In the meantime:

• We must reimplement NoDebugHeap as a module
• It would be great to fix #404 as well

[Itms]

I have everything ready to be committed at ​https://github.com/na-Itms/0ad/tree/premake5!

It includes the work performed by zsol, some updates, it includes a correct way of removing the debug heap, it fixes #404 (only on premake5) and all build scripts have been updated to support experimental testing of premake5 through the --premake5 command-line option.

You can use the github branch for eased reviewing and I will upload a SVN patch to our new Phabricator system.

[Zsolt Dollenstein]

Awesome!

[Itms]

In 19188:

Cleanup of NASM. It has been unused for ages (r9891) and we still have legacy code lines in our premake scripts. We also carry an unused binary for Windows.

By removing this we don't need to add NASM support to premake5, refs #3729.

Reviewed By: leper

Differential Revision: ​https://code.wildfiregames.com/D97

[Itms]

In 20366:

Alpha 12 version of Premake 5, including prebuilt binary for Windows.
Directly taken from ​https://premake.github.io/.

Refs #3729.

[Itms]

In 20381:

Migrate to premake5, fixes #3729.
Make pyrogenesis and tests depend on Collada, fixes #404.

This commit includes custom modules for CxxTest and pkg-config support that can be improved upon in the future. It also includes all necessary changes to the build scripts, but the new premake5 features are not fully exploited yet.

With this change, premake5 becomes the default, but CI scripts on Unix will continue using premake4 for a while, in order to avoid regressions.

Includes code by zsol.
Reviewed by: wraitii, leper
Differential Revision: ​https://code.wildfiregames.com/D72

[s0600204]

May I make a request for the .gitignore file in the 0ad github mirror to be updated so that the files premake5 generates inside the build/premake/premake5 folder are ignored? (There are already lines for premake4 in the file.)

[Itms]

Done, thank you for the reminder! The new commit will be pushed to GitLab as well during tomorrow's automatic update of the mirrors.

[Itms]

In 20560:

Remove hack from cxxtest premake module, refs #3729.
This fixes an issue where tests wouldn't build without precompiled headers.

Tested By: leper
Differential Revision: ​https://code.wildfiregames.com/D1068

[Itms]

In 21955:

Drop premake4 support, refs #3729. premake4 has been unused for a long time now, and was only left available as a safety net.

Differential Revision: ​https://code.wildfiregames.com/D1275