Skip to main content

10 posts tagged with "community-updates"

View All Tags

· 4 min read
starkos

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.

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.

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.

· 4 min read
starkos

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.

Community Contributions

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

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.

· 3 min read
starkos

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

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.

· 2 min read
starkos

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.

Meanwhile in V5

The community making the world a better place…

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.

· 5 min read
starkos

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.

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.

· 5 min read
starkos

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

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

· 3 min read
starkos

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

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

· One min read
starkos

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

· 2 min read
starkos

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.

Completed Tasks:

· 2 min read
starkos

Say hello to the new Premake OpenCollective!

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)

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