Milestones​

1. Explicit APIs for Flags: In the past, Premake has support various flags for project generation, such as MFC and LinkTimeOptimization. In the 5.0 stable release, all flags will have been replaced by dedicated APIs. The current development builds have already begun this process.
2. Deprecation and Removal of the gmake Exporter: For many years now, the gmake2 exporter has been our suggested generator for GNU Makefiles. As the 5.0 stable release approaches, gmake will be moved to gmakelegacy and gmake2 will become gmake. It is encouraged that users that are still using the legacy gmake exporter to try gmake2 and report any deficiencies. The deprecation and removal process will happen over the next several beta releases, with planned complete removal within 2025.
3. Removal of Existing Deprecated APIs: There are many existing APIs that have been deprecated for several releases now in Premake, both functions and enumerations. To reduce the surface space of the API, existing deprecated APIs with replacements will be removed. Deprecated APIs without a direct replacement will be provided with either a replacement API or instructions on how to replace the behavior (where possible).

Key Planned Improvements​

1. Better Documentation: For the 5.0 release, the Premake team will be ensuring that all APIs and public-facing behaviors are sufficiently documented. This includes making sure documentation exists for each of these APIs, as well as sufficient examples of their usage. In addition to increased documentation of the Premake APIs, the guides on how to use and extend Premake will be reviewed to ensure they still demonstrate best practices and reflect upcoming API changes. The documentation will also be reviewed to ensure that there are sufficient examples of extending Premake's functionality.
2. General Bug Fixes: There are currently many open bug reports on GitHub for Premake. The team plans to prioritize the bugs and add fixes and tests where possible to prevent future regressions.
3. Improved Extension Support: In Premake 5.0-beta3, extending core functionality in Premake, especially exporters, is tedious. As the 5.0 stable release approaches, the team plans to review the mechanisms to extend toolsets and exporters. This may incur a breaking change to external modules using the existing extension mechanisms; however, documentation will be updated as these occur as well as a transition period. For these changes, community feedback is highly encouraged to make sure this is done in a way that everyone benefits from.
4. Improved CI: Currently, Premake has many build pipelines for verifying builds on various architectures, as well as running the test suites on those platforms. We are investigating improvements to the CI process, such as improved release artifact generation and more robust pipelines. This effort will also include general improvements to the release creation process.
5. Increased Testing Coverage: Premake currently has a large suite of tests, but there are gaps. As part of our push to 5.0, the development team plans to identify and add tests for the gaps in both our public API and internal functionality.

These goals are not all encompassing of Premake 5.0's first stable release, but summarize the high level milestones that the team intends to meet. We look forward to any feedback you have regarding the upcoming changes to Premake. If you are looking to contribute to Premake but don't know where to start, take a look at the GitHub issues list or open a discussion and a member of the team will be able to direct you to where to begin.

Premake would not be possible without the support of the community, our contributors, and our sponsors on Open Collective. Thank you for your continued support throughout this exciting journey towards 5.0.

The Premake Team

Road to Premake 5.0​

Most of the heavy lifting for Premake 5.0 is done, but there are a few major milestones left for leaving beta and going to full release.

1. Deprecation and removal of the flags API. Flags are a remenant of older models. Instead, flags will be migrated to the idiomatic Premake approach of dedicated APIs. This isn't going to be as trivial as "On" and "Off", as many of these flags represent a larger group of behaviors.

2. Deprecation and removal of the gmake exporter in favor of gmake2. This has been one of the goals for many years now, and we're confident that gmake2 is in a spot where it can be "promoted" to the primary GNU makefile exporter. In the next release, gmake will likely be renamed and deprecated, and gmake will describe the gmake2 exporter. This will be a breaking change, but we feel it is the best way forward to remove the bifurcation of the makefile exporter. Until the time when we do remove the legacy gmake exporter, users current leveraging the legacy exporter are encouraged to try out the gmake2 exporter and report any defects or feature deficiencies in order to make the change as seamless as possible.

In order to make sure we capture the needs of users for the 5.0 stable release, I encourage you to open issues or discussions to ensure the transition to 5.0 is an easy user experience.

{/* truncate */}

Community Contributions​

• #1841 Update shadertype.md (@TylerDahl)
• #1842 Update shaderobjectfileoutput.md (@TylerDahl)
• #1843 Update shadermodel.md (@TylerDahl)
• #1942 Release/v5.0 beta2 (@premake)
• #1951 Fix custom build with missing directory (@Jarod42)
• #1952 vstudio: add usestandardpreprocessor option (@flakey5)
• #1954 Add newoption.catagory to documentation, mark os.is as deprecated (@thomashope)
• #1959 Use admonitions in documentation for things marked as deprecated (@thomashope)
• #1970 Updated Android docs (@LORgames)
• #1971 Fixed a couple of issues with the Custom Rules docs (@LORgames)
• #1975 Strip linking decorators for sibling projects (@LORgames)
• #1976 Android projects use IncludePath instead of ExternalIncludePath (@LORgames)
• #1978 Added support for CopyFileToFolders via Copy buildaction (@LORgames)
• #1980 Added UWP support for VS projects (@LORgames)
• #1981 Update usefullpaths.md (@nepp95)
• #1985 Update defaultplatform.md (@GiacomoMaino)
• #1992 Add AntTarget to vsandroid project file (@0x416c69)
• #1997 Add validation for toolset. (@Jarod42)
• #2003 Allow to specify "--cc=msc" as command line. (@Jarod42)
• #2004 Handle entrypoint for msc. (@Jarod42)
• #2006 externalwarnings, externalanglebrackets, externalincludedirs was already available in vs2019 (@Jarod42)
• #2009 Fix typos in comment. (@Jarod42)
• #2010 Typo fix (@brno32)
• #2011 Add support for unity builds (@Sharlock93)
• #2022 Fix Debian build recepie. (@KOLANICH-tools)
• #2023 Fix support of openmp for visual studio with clang toolset. (@Jarod42)
• #2024 Fix typo in bytecode description. (@Jarod42)
• #2025 Fix missing targets file issue in some C++ nuget packages (@hanagasira)
• #2027 sanitize { "Address" } should set link flags too for gcc/clang. (@Jarod42)
• #2028 Add support for idirafter flag in GCC/Clang (@nickclark2016)
• #2032 Change to minimize differences after Codelite re-save the file (@Jarod42)
• #2034 Robustify http.get tests with retry. (@Jarod42)
• #2039 gmake2: Fix detecting msdos vs posix shell (@Peter0x44)
• #2042 Fix compileas "C" and "C++" for gcc (shared with clang). (@Jarod42)
• #2052 Fix typo (@rafaelcn)
• #2061 Fixed issue with Codelite unit test (@LORgames)
• #2064 Updated actions from v2 to v3 (@LORgames)
• #2066 Improve error message of include (@Jarod42)
• #2070 Add support of prelink steps (similar to prebuild steps) for Codelite. (@Jarod42)
• #2072 Fix prelink step dependencies for gmake (to be done after compilation). (@Jarod42)
• #2075 remove trailing whitespaces and add new line at eof (@hanagasira)
• #2076 Allow to select specific version of msc in command line. (@Jarod42)
• #2081 Add some missing flags for msc toolset (@Jarod42)
• #2084 Update debugdir.md docs to clarify feature support (@thomashope)
• #2087 Add clarification for relative paths (@learn-more)
• #2088 Fix nil indexing for codelite (@Jarod42)
• #2090 Add support to undefines for Codelite. (@Jarod42)
• #2102 remove reference to non existent example. (@mcarlson-nvidia)
• #2104 Add VS2022 to list of valid kinds for Android Packaging (@premake)
• #2117 Require unistd.h for macosx in libzip (@nickclark2016)
• #2118 Changes target of HTTP tests to hopefully resolve test issues in CI (@nickclark2016)
• #2122 Fix premake.findProjectScript of previous commit. (@Jarod42)
• #2127 Fixes for using debugger under Linux (@vadz)
• #2131 Use call array for MSVS filters file generation too (@vadz)
• #2135 Fix libzip missing a library (@KanuX-14)
• #2172 Custom LLVM Versions for VS2019+ (@nickclark2016)
• #2187 Enable code analysis via clang-tidy in Visual Studio (@theComputeKid)
• #2194 [vs*] Allow to have per-file cdialect/cppdialect. (@Jarod42)
• #2195 [vs2010+] Handle compileas for files with "unknown" extensions. (@Jarod42)
• #2203 Add CA root certificate path for Haiku (@augiedoggie)
• #2217 Add Library to available shadertypes (@vkaytsanov)
• #2237 [CI] add dependabot.yml to maintain version action up to date (@Jarod42)
• #2238 Bump the github-actions group with 3 updates (@premake)
• #2243 Fix stack manipulation in Premake's luaL_loadfilex override. (@tritao)
• #2251 Add a os.hostarch() function to get the host system architecture. (@tritao)
• #2252 Document os.rename and os.getenv APIs (@tritao)
• #2253 Add term.clearToEndOfLine and term.moveLeft API additions. (@tritao)
• #2254 Adds desktop system tag to desktop systems. (@tritao)
• #2255 Move sanitize, visibility and inlinesvisibility to shared table. (@alex-rass-88)
• #2261 Add tests for table.merge. (@tritao)
• #2263 Adds a new os.targetarch() function. (@tritao)
• #2264 Show error messages from broken includes (@richard-sim)
• #2268 Re-structure common docs files into sub-folders. (@tritao)
• #2269 Upgrade docs to latest Docusaurus version. (@tritao)
• #2271 Add linker flag and LLD support. (@tritao)
• #2272 Fixed issue with include failing to find embedded files (@LORgames)
• #2274 Port Premake to Cosmopolitan Libc (@tritao)
• #2277 Add C++23 cppdialect (@jlaumon)
• #2278 Prevent empty arrays as expected values for test.contains and test.excludes (@LORgames)
• #2279 Added ci job to simplify required checks in PRs (@LORgames)
• #2280 Upgrade libcurl to latest. (@tritao)
• #2281 Fix vstudio/MSC not supporting the C++23 flag yet (@jlaumon)
• #2283 Miscelanneous cleanups (@tritao)
• #2284 Fix os.host for Cosmopolitan build (@tritao)
• #2287 [doc] Write doc for unsignedchar (@Jarod42)
• #2294 Add projects web and github (@Jarod42)
• #2299 Remove generated "website/node_modules"'s files from project (@Jarod42)
• #2301 Fix spelling insice -> inside (@jonesy-b-dev)
• #2316 Update modules.md (@day-garwood)

Additional gratitude and good wishes to everyone who helped review pull requests and triage issues this cycle. Projects like this don't work without you.

A big shout out to our premier sponsor Cfx.re and all our monthly backers—be sure to check out their work and support them back if you can!

We welcome questions, suggestions, and concerns. Message or DM us at @premakeapp or open a discussion on GitHub.

After one of the world's longest alpha cycles, Premake5 has finally entered beta! I don't know about you, but I definitely had a drink to celebrate. Might have been two, even. Probably.

As previously discussed, we've started the process of stabilizing 5.0 and shifting breaking changes over to the new v6.x branch. We've set up a milestone to track our progress toward a stable 5.0 release, and this is the first step in working it down.

Most of the changes in the queue are under-the-hood: release automation, bootstrapping, and unit test fixes. The only potentially significant breaking change remaining is promoting the gmake2 exporter, which I will be prioritizing for the next beta. If you happen to still be using the older gmake exporter, please give gmake2 a try and let us know if you encounter issues! Most fixes have been going to gmake2 lately, so we expect your experience will be a good one.

{/* truncate */}

Premake6​

As of this morning, Premake6 is now "self-hosting" on Visual Studio, Make, and Xcode, meaning that it can generate its own project files, which can then be used to build Premake6. This is a big milestone, since we can now move past isolated unit tests and actually verify our changes with working builds on all three toolsets. All of Premake's core functionality is now fully online, and we're shifting our focus to prioritizing and porting individual features. Still lots of hardcoded settings and to-dos, but full speed ahead!

(Speaking of which: I know the pace is slow—definitely slower than I would like—but thanks to our backers it’s steady progress. For a bunch of nights-and-weekends part-timers we’re doing alright.)

I'm currently taking a bug fix & cleanup pass over what we have so far, and filling in gaps in the documentation to make sure we're not leaving too much debt behind. High priority next steps include rethinking how we abstract toolsets like GCC & Clang, so we can push ahead implementing new features on top of those abstractions. And then implementing links and (...drum roll...) usages (yes, really!) so we can start linking projects and their dependencies together.

Hat tip to @nickclark2016 for tackling the new makefile exporter!

Community Contributions​

Yay open source development! 🎉 Big shout out to everyone who took the time to contribute this cycle.

• #1629 Add support for macOS universal binary (@tempura-sukiyaki)
• #1661 Add frameworkdirs support to gmake & gmake2 with gcc/clang toolsets (@depinxi)
• #1672 C# Symbol Premake → VS Mapping Changes (@nickclark2016)
• #1680 Fix some build issues with mingw (@Biswa96)
• #1687 Update deprecated entry for newaction (@Jarod42)
• #1704 VS2022 Exporter (@nickclark2016)
• #1710 Add support for SSE 4.2 (@ActuallyaDeviloper)
• #1712 Add OpenMP support for Visual Studio (@T-rvw)
• #1713 Upgrade docusaurus version to beta.6 (@KyrietS)
• #1715 Docs maintenance (@KyrietS)
• #1718 Deprecate configuration() (@starkos)
• #1720 Improve justmycode (@T-rvw)
• #1721 Add custom rules for Gmake2 & Codelite (@Jarod42)
• #1723 Add configuration condition to VS csproj references ItemGroup (@cicanci)
• #1726 Updated cdialect and cppdialect docs (@LORgames)
• #1727 Updated architecture docs (@LORgames)
• #1728 Add action to check for and generate missing documentation (@LORgames)
• #1730 Added missing compileas values to docs (@LORgames)
• #1734 Add VS 2022 bootstrapping support (@afxw)
• #1736 Update showcase to include Orx (@sausagejohnson)
• #1737 Change Visual Studio Version to 17 so sln is opened with VS2022 (@simco50)
• #1739 Fix #1628 failing macOS os.findlib() test (@starkos)
• #1744 Add check for missing values in documentation (@LORgames)
• #1745 Adding documentation for module options (@hannes-harnisch)
• #1749 Changed C++20 to emit C++20 instead of C++Latest in MSVC (@nickclark2016)
• #1752 Added C17/GNU17 support to gmake/gmake2 exporters (@nickclark2016)
• #1753 Update documentation link in README (@nickclark2016)

Extra thanks to the unsung heroes not mentioned here who helped review pull requests, triage issues, and generally keep the machine humming.

Our Sponsors​

Which brings us at last to our regular thank you & shout out to our premier sponsor Cfx.re as well as all our monthly backers—be sure to check out their work and support them back if you can!

I welcome questions, suggestions, and concerns. Message or DM me at @premakeapp, email at starkos@industriousone.com, or open a discussion on GitHub.

Branch, don't backport​

In the last update, I asked for input on where the work going into premake-next should end up: branch a new 6.x major version, or backport the changes to 5.x? There was solid consensus that premake-next should be treated as a new major version, with v5 upgraded to a stable release for on-going support. Thanks to everyone who participated and offered feedback!

With that settled, I've archived the premake-next repository and moved all development to a new 6.x branch on premake-core. As of the next release, I'll be upgrading the status of 5.0 from alpha to beta, with the intention of making the first stable release shortly.

The Path to 5.0​

Premake's perpetual alpha status causes confusion and makes it difficult for some people to adopt. We've been hanging on to that label in the hope we'd get a chance to overhaul the makefile and Xcode exporters. But now that we have a v6 branch it makes sense break things over there instead, and get v5 to a stable release sooner rather than later.

I've opened a 5.0 milestone on the project and will be assigning a few issues to myself there. If you have a backward-compatibility breaking change that you feel must get in before 5.0 becomes stable, open or escalate an issue ASAP so we can get it on the roadmap. And as ever, we're all really busy, so any help getting this over the finish line is much appreciated!

Premake6​

In other news, Premake6 can now generate its own Visual Studio project files and bootstrap itself. That doesn't sound very impressive, but it does means that all of the under the hood stuff is now online and working as intended, and a full vertical slice has been completed. 🎉

@nickclark2016 has volunteered to begin looking into a new-and-improved makefile exporter, which frees me up to start looking at Xcode and improving the way we represent toolsets like Clang and GCC. The stable release of 5.0 is likely to take up all the air in the room for a bit, but hopefully I can report progress on those soon.

{/* truncate */}

Community Contributions​

The community keeps things rolling—many thanks to everyone listed here!

• #1570 Initial C++20 module support for Visual Studio (@hannes-harnisch)
• #1625 Remove "*ng" action deprecation and auto-fix (@noresources)
• #1635 Fix typo in Using Premake documentation (@abhiss)
• #1638 Fix broken links in docs (@KyrietS)
• #1642 Fix spelling mistake (@Troplo)
• #1644 Fix author name and update time on pages (@KyrietS)
• #1645 Add missing support for prebuildmessage/postbuildmessage for Codelite (@Jarod42)
• #1649 Fix curl header search path (@depinxi)
• #1654 xcode4: Fix missing link of sibling project with custom targetextension (@depinxi)
• #1655 Compiler Version support for Visual Studion 2017+ (@nickclark2016)
• #1657 Renormalize line endings (@nickclark2016)
• #1663 compilebuildoutputs make some comments obsolete (@Jarod42)
• #1668 Fix v6 bootstrapping from v5 (@starkos)
• #1673 Updated sidebar to include toolsversion link (@nickclark2016)
• #1662 Handle buildcommand for Codelite (@Jarod42)
• #1658 Fix D module compiler output for visual studio (@nickclark2016)

Additional gratitude and good wishes to everyone who helped review pull requests and triage issues this cycle. Projects like this don't work without you.

A big shout out to our premier sponsor Cfx.re and all our monthly backers—be sure to check out their work and support them back if you can!

I welcome questions, suggestions, and concerns. Message or DM me at @premakeapp, email at starkos@industriousone.com, or open a discussion on GitHub.

The biggest update this cycle: a new and very much improved Premake website. Built with Docusaurus, the new site gives us better navigation and search, a place for news (with RSS!) and it sure looks a hell of a lot better than my "make a website in 20 minutes" version we were running before.

Many thanks to @KyrietS for kicking off the process and the help with bootstrapping and content migration! 🙌

On the process side, this upgrade means that the documentation now lives with the code. Anyone can contribute by submitting a pull request, and the docs can now be updated right alongside the code that implements the changes. I'm optimistic this will help us improve the accuracy and timeliness of the documentation.

(The GitHub wiki served us well in its time, and is still there for the historical record. But people tended to not keep it up to date with the code. Navigation and search wasn't as nice. And permissions were all-or-nothing; there was no great way to strike a balance between community edits and preventing spam and vandalism.)

Very happy about this.

Premake v5.0-alpha16 Released​

I…did not realize how long it had been since there was a proper release. Pandemic and all that. I've corrected the matter: v5.0-alpha16 is now available, with lots of good improvements. See the full changelog here.

(By the way, if anyone out there has a knack for build automation I'd love to see these releases automated. Get in touch!)

{/* truncate */}

RFC: Branch or Backport​

I also finally sat down and opened an RFC to figure out what to do with the work going on over at premake-next: branch and push ahead to a v6, or backport the improvements into v5? I've gone back and forth on it but came down on the side of branching; now I'd love to hear what the community thinks. Join the discussion here.

What's Next for Next​

While we're discussing, I'm hoping to get back to premake-next, finish up the first few build switches (defines, include directories, that kind of thing), and show them working for both project and file-level configurations, exported for Visual Studio.

Thanks 🙏​

As I do but never do enough, many thanks to @samsinsane, @KyrietS, and everyone who contributed code and helped review PRs and issues this cycle.

Many thanks to CitizenFX Collective and all our monthly backers who allow me to work on Premake instead of shilling for client work. Couldn't be doing this without your generosity.

And as ever: I welcome questions, suggestions, and concerns. Message or DM me at @premakeapp, email at starkos@industriousone.com, or open a discussion on GitHub.

~st.

What's Next​

• For real this time, first thing: step away from the code and open an RFC on merging the projects. I've never been great at that whole "stepping away from the code" thing but I'll do my very best.
• Work with @KyrietS to bring a new & improved documentation system online.

Longer term: push to get the new code to the point where it can generate its own Visual Studio project files. I've actually done a good chunk of work on this, but wasn't quite able to bring it home this month. Then do the same with Xcode.

{/* truncate */}

Meanwhile in V5​

The community making the world a better place…

• #1551 Add NetCore to CLR API (@nickclark2016)
• #1554 [clang] Use llvm-ar linker when LTO flag is set (@JoelLinn)
• #1552 Fix MSC LTO, runtime, subsystem (@JoelLinn)
• #1560 Add newer shader versions (@dpeter99)
• #1562 Remove moduledownloader to avoid RCE (@gibbed)
• #1564 Improve .NET version check to support net5.0+ (@ClxS)
• #1565 Move AllowUnsafeBlocks to project level property (@ClxS)
• #1566 Set execute bit on Bootstrap.bat (@ratzlaff)
• #1571 Add useFullPaths for Visual Studio projects (@cos-public)
• #1576 Mesh and amplification shader type for Visual Studio (@pkurth)

Thanks!​

Kudos and a call out to @samsinsane and the contributors listed above, CitizenFX Collective for their continued strong financial support, and to all of our monthly backers! Be sure to check out their work and support them back if you can!

Lots of big changes happening—I welcome questions, suggestions, and concerns. Everything is up for discussion, from the feature set to the coding style. You can message or DM me at @premakeapp, email at starkos@industriousone.com, or open an issue on the premake-next GitHub project.

~st.

The focus for this cycle was getting an exporter—I settled on Visual Studio—up and running and able to generate a basic, mostly hardcoded workspace and project. More details below, but TL;DR:

• All of the core systems are now in play, with the exception of toolsets and token expansion (more on those below)
• The workspace, project, location, and filename scripting APIs are implemented, as well as the ability to declare conditional configuration blocks
• A very rudimentary Visual Studio exporter is now in place, with the ability to generate mostly hardcoded C/C++ solutions and projects at the specified locations and filenames

What's Next for Next​

For those of you who are more interested in "is it done yet?" than "what's new?", here's my current thinking on what comes next:

• Decide if/how/when/where these improvements get merged (or not) with Premake5. I have some thoughts of course, and will be opening an RFC on the issue tracker shortly to gather feedback. I'l announce it on @premakeapp when I do.
• Get build configurations & files online—be able to generate simple Visual Studio C/C++ projects with no extra switches or dependencies
• Get Make and Xcode up to same level as Visual Studio—going to be some rewriting here as that code has seen a lot of wear and tear, and needs to be brought up to the latest code conventions
• Decide on and build out the new solution for toolset adapters—I'll open an RFC on the issue tracker for this as well
• Add kind, links, and the most important switches (e.g. includedirs, symbols, optimize)—be able to support the most common C/C++ builds

Somewhere in there I should also backfill the documentation so people know what's working. All of this is subject to change and peer pressure, feedback welcome.

{/* truncate */}

What's New​

I'm doing my best to keep an inventory of the major changes here; let me know if you spot anything missing (and thanks to those who have already).

Scoping is now explicit​

Premake4/5's scoping rules have always been a big gotcha. Tough for newcomers, easy to break even for experienced users, and very difficult to debug. I'm proposing that scoping be made explicit using function callbacks. Here's what a simple Hello World script might look with the new approach (apologies again for the images; if OpenCollective's editor supports code blocks I haven't been able to find them yet).

workspace('HelloWorld', function ()
	configurations { 'Debug', 'Release' }

	project('HelloWorld', function ()
		kind 'ConsoleApplication'
		files { '**.h', '**.cpp' }

		when({ configurations='Debug' }, function ()
			defines { 'DEBUG' }
			symbols 'On'
		end)

		when({ configurations='Release' }, function ()
			defines { 'NDEBUG' }
			optimize 'On'
		end)
	end)
end)

(Keep in mind, only workspace, project, location, and filename are implemented so far, the rest will be coming online ASAP. The name when() is a proposal, feedback welcome.)

Under the hood, the provided configuration functions are called immediately. Under the hood, that workspace() helper looks like:

function workspace(name, fn)
	workspaces(name)
	when({ workspaces = name }, function ()
		baseDir(_SCRIPT_DIR)
		fn()
	end)
end)

…so things still work the same as in Premake5, but scopes are now clearly explicit, and the indentation actually makes real sense (and gets syntax-aware editor support.

The syntax is, unfortunately, noisy. Down the road I wouldn't be opposed to tweaking Premake's embedded Lua runtime to provide a simpler syntax.

Exporters are no longer version specific​

The command to export a project for Visual Studio now looks like this:

# target the latest version of Visual Studio we support
premake6 vstudio

# target a specific version
premake6 vstudio=2017

As anyone working on the Visual Studio or Xcode exporters is well aware, tool vendors are no longer waiting for the next major release to add features and change project formats. While more work is needed, the new command line syntax at least opens up the possibility of doing something like…

premake6 vstudio=14.0.25431.01

…which will allow us to support people who need to target a specific build of one of these tools.

Container hierarchy is now more flexible​

In Premake4+, projects were required to be declared within one and only one workspace; this is now loosened up. The earlier Hello, World example could also be written like:

workspaces { 'HelloWorld' }
projects { 'HelloWorld' }

when({ 'workspaces:HelloWorld' }, function ()
	projects { 'HelloWorld' }
end)

Projects can be shared between workspaces, or even be completely standalone, if the target toolset supports it.

What's next​

I covered this above, but an RFC to coordinate v5 vs. vNext development is currently next on my to-do list.

These are big changes and I welcome questions, suggestions, and concerns. Everything is up for discussion, from the feature set, to the coding style. You can message or DM me at @premakeapp, email at starkos@industriousone.com, or open an issue on the premake-next GitHub project.

Thanks to our supporters! 🎉​

Many thanks to my co-maintainer @samsinsane, who has been doing a stellar job of keeping the shop running while I've been distracted with the new code, and to @nickclark2016, @noresources, @nickgravelyn, @Jarod42, and @cos-public for helping out with issues and new pull requests—very much appreciated!

And another big shout out to CitizenFX Collective for their continued strong financial support—as well as [all of our monthly backers](https://opencollective.com/premake#section-contributors!

Doing my best to get this new version fully up to speed ASAP for all of you.

~st.

I am happy to be able to say that I've wrapped up the first round of development on the new storage & query system. I threw every edge case I could think of at it and was able to, eventually, pass them all.

What's new with the new system?​

Learning my lesson from past development, I did my best to make this new version as open-ended and unconstrained as possible.

A proper API. The storage and query API have been cleaned up and condensed to make things easier and more powerful for module authors. (Sorry for the inline images, the OpenCollective editor won't allow me to author code blocks?)

{/* truncate */}

-- create a new query, targeting a particular "environment";
-- returns the global configuration for that environment
local global = store:query({ system='windows', action='vs2019' })

-- from the global scope, get the configuration for a specific workspace
local wks = global:select({ workspaces='Workspace1' })

-- from that workspace, get the configuration for a specific project
local prj = wks:select({ projects='Project1' })

No containers. Unlike the v5 system, there is no hardcoded "container" hierarchy. "Scopes" are arbitrary and defined by the query author, making new or ad hoc scopes trivial to implement.

-- configuration for Project1 common to all workspaces
local prj1 = global:select({ projects='Project1' })

-- all DLL configuration
local cfg = global:select({ kind='SharedLib' })

Fine-grained inheritance. Inheritance in v5 was baked into the system and difficult to modify or work around. The new system allows inheritance to be enabled (or not) between any "scopes", or even on a per-fetch basis.

-- this project inherits values from the workspace
local prj1 = wks
	:select({ projects='Project1' })
	:inheritValues()

-- this project does not inherit workspace values
local prj2 = wks:
	:select({ projects='Project2' })

-- inheritance can then be enabled for a particular fetch
prj2:inheritValues().fetch('defines')

-- get all configuration specific to the Win64 debug build, without
-- inheriting anything from the project. This was really difficult
-- to do in the previous system
local files = prj2
	:select({ platforms='Win64', configurations='Debug' })

No more file configurations. This one pleases me greatly: file-level configuration is now no different than anything else. This will make it much easier to implement per-file configuration settings going forward.

local file = prj:select({ files='Hello.cpp' })
local fileCfg = file:select({ configurations='Debug' })
local fileDefines = fileCfg:fetch('defines')

No "magic" fields. In v5, certain fields received special processing to enable out-of-order evaluation for situations like the one shown below. This worked for most projects, but not for everyone, and it added extra processing and overhead. The new system is able to handle situations like these as a general case, with no workarounds.

filter { kind='SharedLib' }  -- don't yet know what `kind` will be
	defines 'DLL_EXPORT'

project 'Project1'
	kind 'SharedLib'   -- need to go back and get that earlier define

Reduced configuration constraints. It now possible to share projects between workspaces, just as you would any other configuration. Containers which previously required the use of special APIs now work like any other field. Using the v5 scripting syntax (which isn't implemented in the new version), that means you can do things like:

workspaces { 'Workspace1', 'Workspace2' }
projects { 'Project1', 'Project2' }

filter { 'workspaces:Workspace*' }
	projects { 'Project1' }

On performance​

When I announced that I was working on a new system, several people were quick to raise performance as a critical concern. While it is too soon for performance testing—this is just the "keep it simple; make it work" version—I have tried to design the overall approach for optimizability. The new system is simpler and "flatter", provides more opportunities for caching intermediate results, and should translate to C reasonably well. Once the new system has been proven fit for purpose and there are enough features in place to run a real world test I will loop back to complete those optimizations.

Next steps​

All of these improvements and advances are academic until you can actually generate some output, so that's next on my list. In order to cut to the chase and get us to a "v5 vs. v6" decision as quickly as possible, without getting mired in all of the complexities of targeting a specific toolset, I'm planning to build a JSON export module over the new code. (This is something I've wanted in the past to assist with tooling, automation and visualization anyway.) That should allow me to quickly build out the scaffolding and APIs required by all exporters, as well as provide a good testbed for bringing the remaining features online as we move ahead. Feedback on that approach, or alternative suggestions, are welcome.

v5 vs. v6​

It's my hope that with an exporter in place folks will have enough to see and touch to consider where things go next. Do we backport the new code to v5 and rework all of the existing actions, potentially breaking existing projects? Or do we flip the bit on v5, mark it "stable", and push ahead with a v6 instead? (I have an opinion, but keeping an open mind.) When the time comes I'll open an RFC issue on GitHub so everyone can have their say on the matter.

Feedback is welcome and appreciated!​

These are big changes and I welcome questions, suggestions, and concerns. Everything is up for discussion, from the feature set, to the coding style. You can message or DM me at @premakeapp, email at starkos@industriousone.com, or open an issue on the premake-next GitHub project.

And as we do: a shout out to CitizenFX Collective and Industrious One and everyone else who has helped back us so far. Getting this new system shipped crosses a big dependency off the to-do list, and I'm not sure it ever would have seen the light of day without your help. Many and sincere thanks to all of you! 🙌

~st.

Inbox Zero​

Rather than diving right back into premake-next, it felt best to take a turn clearing out the lingering pull requests that have been haunting our queue, in some cases for years now. @saminsane has been doing a fantastic job triaging your new PRs and getting them merged; I just had to deal with the older ones which, for various reasons, couldn't easily be landed.

Long story short: after several years, we're at inbox zero. Check out Premake's recently closed PR list for the details on how we got there.

Whew!

Alpha-15​

With inbox zero reached, we also cut a new 5.0 alpha release with over 50 changes and fixes, from over 20 different contributors. Nicely done everyone, and thanks! 🙌

{/* truncate */}

Premake5 Stable?​

Speaking of changes and releases, #1423 from @dvzrz asks whether it's (finally) time to cut a stable release of Premake5. Fair question! As I responded on the issue, @saminsane and I have discussed this before, and our general feeling is that there are too many big, breaking changes that still need to be made.

Gmake/Gmake2 situation needs to be sorted, the Xcode exporter needs to be made fit for use, both Gmake & Xcode need to be made module-friendly, and the toolset abstractions need to be reworked to support more real-world setups. The internal APIs really should be cleaned up and naming conventions standardized for module developers.

Help tackling those areas is, of course, very welcome.

That said…

Back to Next​

With the PRs cleared and a new alpha released, I'm now turning my attention back to premake-next. I'm going to adjust the plan a bit and focus on getting the new storage and query systems online ASAP. Fixing these two systems is the point of whole exercise, and it seems worth getting more eyes on them sooner than later, even if the configuration blocks have to be manually assembled (i.e. the convenience functions like workspace(), project(), defines(), files(), etc. won't be there yet…it will make sense when you see it).

So long and thanks for all the fish​

As ever, big and many thanks to everyone who contributed to alpha-15, and to everyone who continues to support the Premake OpenCollective, with an extra special 🎉 to new sponsors Emilio Lopez and Benjamin Schlotter, and our stalwart benefactor CitizenFX Collective. I wouldn't be able to get any of this done without your help, and I truly appreciate it.

Stay safe!

~st.

(Your feedback is welcome and appreciated—come find us at github.com/premake or @premakeapp.)

If you haven't been following along, you can see what I've been up to, and why, over at my premake-next repository on GitHub. I'm also posting regular updates here, as well as at @premakeapp.

Many thanks to CitizenFX Collective and Industrious One, and to new contributors Renaud Guillard, Wracky, and MiCroN3000. Your generous support makes this possible, and is very much appreciated! 🎉

~st.

(Your feedback is welcome and appreciated—come find us at github.com/premake or @premakeapp.)

{/* truncate */}

…more importantly, while I have this opportunity to log solid blocks of time to Premake (thank you!), I'm taking on its biggest weakness: the project configuration system, the heart of the program that stores your scripted project settings and serves them back to the exporters and actions. The shortcomings in this system are the reason why it's so difficult to support per-file configurations, why we struggle to express makefiles succinctly, and why we can't do a better job of scaling up to large numbers of platforms/architectures/toolsets/etc. Fixing this fixes many things.

To get this done in the most expedient way, and with the least disruption, I’ve spun up a new working space at premake-next. For those interested, you can read more about what I'm doing, why, and where it's all headed over there. And I’ll also continue posting regular updates here on the Collective.

Which brings me to the part where I give a huge THANK YOU! to our continuing sponsors CitizenFX Collective and Industrious One. I would not be able to tackle any of this were it not for your continued support. 🙌

For the next cycle, I plan to start filling in the details of an improved configuration storage approach and, if possible, merge another pull request or two.

~st.

{/* truncate */}

Completed Tasks:

• Boostrapped Premake-next
• Closed PR #1259 with PR #1355
• Closed PR #1271 with PR #1356
• Closed PR #1063 with PR #1357
• Merged new PRs #1345, 1351, 1352, 1353, 1358
• Closed issue #38 and PR #624 with feature request #1344
• Closed issue #237 and PR #956 with feature request #1346
• Closed stale PRs #968, 1003, 1054, 1112, 1119, 1196, 1252, 1301
• Added new "Get help" and "Ask a question" issue templates; improved "Report a bug" and "Request a feature" templates

As I'm sure you are all too aware, Premake development has slowed to a trickle. I've been taking on more and more client work to keep the books balanced, and there simply isn't any useful time left over at the end of the day. A not uncommon problem!

So I'm trying an experiment: can we, as a community, create a pool of funding to speed up Premake's development? Is there enough interest to make it happen? If so, I would be delighted to transition hours from client work back to Premake, as well as put funds toward bounties and recognizing contributions from the community.

The experiment is now officially underway. As long as it continues, I'll provide regular updates on our progress and upcoming work. This cycle, I was able to…

• Set up this OpenCollective, enabling the Premake project to accept contributions to fund on-going development and community support (#1314, #1316)

• Register @premakeapp on Twitter for announcements and group communication (and maybe a little self-promotion). Come join us! (#1315)

• Improve the project on-boarding experience with a new README.md and CONTRIBUTING.md (#1324, #1325)

• Improve the collaboration process with new issue, feature, and pull request templates (#1326, #1327)

{/* truncate */}

I'm not charging any expenses against the collective this cycle so we can build up a balance to recognize cool or important contributions from the community. You can track our finances and transactions at any time on our OpenCollective page.

For the next cycle, I'd like to show a little maintainer love by working down (and ideally clearing) the open pull request queue and, time permitting, do a bit of grooming on the open issue list as well. Longer term, I've put a great deal of time and thought into fixing Premake's core configuration engine, which is holding back development on a number of important features. I've figured out how it should work; now I'm puzzling over how to get there from where we are.

Many thanks to [CitizenFX Collective](https://opencollective.com/_fivem](https://opencollective.com/_fivem) and Industrious One for their generous support this cycle. Your contributions make this possible! 🎉

~st.

(Your feedback is welcome and appreciated—come find us at github.com/premake or @premakeapp.)