11 posts tagged with "community-updates"

It's been almost 3 years since the last community update, and over 2 years since the last beta. Without further ado, here are the community contributions fromt the last 2 years.

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.

Premake 5.0-beta1! 🥳​

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.

I can't believe we're already eight months into 2021, how did this happen.

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.

Welcome Website!​

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!)

A quick update this cycle so I can get right back to it: I managed to free up meaningful blocks of time for Premake in February—felt good!—and tackle files and removeFiles, support configuration and platform specific files, and get it all exporting to Visual Studio (…and bulldoze through the rabbit holes along the way). From the user-facing side not a big change, but a hefty commit just the same. The core platform is starting to feel reasonably complete.

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.

Enter the Exporters​

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.

The new storage system has arrived​

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?)

It's been much longer than anticipated since the last community update. I was out of the country for a bit, and then shortly after my return the whole Situation hit the fan and things got crazy for a while. I'm back now, up and running and looking ahead to what's next. I hope all of you are also safe and sound and getting your groove back.

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! 🙌

Just a quick update this time: I had big plans for new features this cycle, but ended up getting swamped in end-of-year deadlines, and was only able to deliver a small portion of what I had intended (and late, at that). Still, I did manage a quick port-and-polish of the unit testing module and all of its dependencies, so I'm well positioned to begin the new user scripting API work in earnest. I will be on the road a fair bit over the next quarter, but I'm still optimistic that I can get enough of the new system online to give folks a sense of where things are headed.

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.)

For this cycle (I work in eight-week cycles and fill in as much Premake work as I can), I completed a long overdue pruning of the pull request backlog. Working up from the oldest, I was able to get it down to just four, all in striking distance of merging and just needing a little follow-up (assistance welcome!). I'll drop a list of all the PRs that were moved at the bottom of this update. Because…

…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.