-
-
Notifications
You must be signed in to change notification settings - Fork 619
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1614 from starkos/website-blog
Set up blog; move community updates
- Loading branch information
Showing
9 changed files
with
420 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
--- | ||
title: "Community Update #1" | ||
tags: [community-updates] | ||
author: starkos | ||
author_url: https://github.com/starkos | ||
author_image_url: https://avatars.githubusercontent.com/u/249247?v=4 | ||
author_title: Premake Admin & Developer | ||
--- | ||
|
||
Say hello to [the new Premake OpenCollective](https://opencollective.com/premake)! | ||
|
||
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](https://opencollective.com/premake), enabling the Premake project to accept contributions to fund on-going development and community support ([#1314](https://github.com/premake/premake-core/pull/1314), [#1316](https://github.com/premake/premake-core/pull/1316)) | ||
|
||
- Register [@premakeapp](https://twitter.com/premakeapp) on Twitter for announcements and group communication (and maybe a little self-promotion). Come join us! ([#1315](https://github.com/premake/premake-core/pull/1315)) | ||
|
||
- Improve the project on-boarding experience with a new [README.md](https://github.com/premake/premake-core/blob/master/README.md) and [CONTRIBUTING.md](https://github.com/premake/premake-core/blob/master/CONTRIBUTING.md) ([#1324](https://github.com/premake/premake-core/pull/1324), [#1325](https://github.com/premake/premake-core/pull/1325)) | ||
|
||
- Improve the collaboration process with new issue, feature, and pull request templates ([#1326](https://github.com/premake/premake-core/pull/1326), [#1327](https://github.com/premake/premake-core/pull/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](https://opencollective.com/premake). | ||
|
||
For the next cycle, I'd like to show a little maintainer love by working down (and ideally clearing) the [open pull request queue](https://github.com/premake/premake-core/pulls) and, time permitting, do a bit of grooming on the [open issue list](https://github.com/premake/premake-core/issues) 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](https://github.com/industriousone/premake-query); now I'm puzzling over [how to get there](https://github.com/starkos/premake-next) from where we are. | ||
|
||
Many thanks to **[CitizenFX Collective](https://opencollective.com/_fivem](https://opencollective.com/_fivem)** and **[Industrious One](https://opencollective.com/industriousone)** 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](https://github.com/premake) or [@premakeapp](https://twitter.com/premakeapp).)_ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
--- | ||
title: "Community Update #2" | ||
tags: [community-updates] | ||
author: starkos | ||
author_url: https://github.com/starkos | ||
author_image_url: https://avatars.githubusercontent.com/u/249247?v=4 | ||
author_title: Premake Admin & Developer | ||
--- | ||
|
||
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](https://github.com/starkos/premake-next/pulls). 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!](https://opencollective.com/premake#section-contributors)), 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](https://github.com/starkos/premake-next). For those interested, you can read more about what I'm doing, why, and where it's all headed [over there](https://github.com/starkos/premake-next). And I’ll also continue posting regular updates [here on the Collective](https://opencollective.com/premake). | ||
|
||
Which brings me to the part where I give a huge THANK YOU! to our continuing sponsors **[CitizenFX Collective](https://opencollective.com/_fivem)** and [Industrious One](https://opencollective.com/industriousone). 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](https://github.com/premake/premake-core/pulls). | ||
|
||
~st. | ||
|
||
**Completed Tasks:** | ||
|
||
- Boostrapped [Premake-next](https://github.com/starkos/premake-next) | ||
- Closed [PR #1259](https://github.com/premake/premake-core/pull/1259) with [PR #1355](https://github.com/premake/premake-core/pull/1355) | ||
- Closed [PR #1271](https://github.com/premake/premake-core/pull/1271) with [PR #1356](https://github.com/premake/premake-core/pull/1356) | ||
- Closed [PR #1063](https://github.com/premake/premake-core/pull/1063) with [PR #1357](https://github.com/premake/premake-core/pull/1357) | ||
- Merged new PRs [#1345](https://github.com/premake/premake-core/pull/1345), [1351](https://github.com/premake/premake-core/pull/1351), [1352](https://github.com/premake/premake-core/pull/1352), [1353](https://github.com/premake/premake-core/pull/1353), [1358](https://github.com/premake/premake-core/pull/1358) | ||
- Closed [issue #38](https://github.com/premake/premake-core/issues/38) and [PR #624](https://github.com/premake/premake-core/pull/624) with [feature request #1344](https://github.com/premake/premake-core/issues/1344) | ||
- Closed [issue #237](https://github.com/premake/premake-core/issues/237) and [PR #956](https://github.com/premake/premake-core/pull/956) with [feature request #1346](https://github.com/premake/premake-core/issues/1346) | ||
- Closed stale PRs [#968](https://github.com/premake/premake-core/pull/968), [1003](https://github.com/premake/premake-core/pull/1003), [1054](https://github.com/premake/premake-core/pull/1054), [1112](https://github.com/premake/premake-core/pull/1112), [1119](https://github.com/premake/premake-core/pull/1119), [1196](https://github.com/premake/premake-core/pull/1196), [1252](https://github.com/premake/premake-core/pull/1252), [1301](https://github.com/premake/premake-core/pull/1301) | ||
- Added new "Get help" and "Ask a question" issue templates; improved "Report a bug" and "Request a feature" templates |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
--- | ||
title: "Community Update #3" | ||
tags: [community-updates] | ||
author: starkos | ||
author_url: https://github.com/starkos | ||
author_image_url: https://avatars.githubusercontent.com/u/249247?v=4 | ||
author_title: Premake Admin & Developer | ||
--- | ||
|
||
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](https://github.com/starkos/premake-next). I'm also posting regular updates here, as well as at [@premakeapp](https://twitter.com/premakeapp). | ||
|
||
Many thanks to **[CitizenFX Collective](https://opencollective.com/_fivem)** and **[Industrious One](https://opencollective.com/industriousone)**, and to new contributors **[Renaud Guillard](https://opencollective.com/renaud-guillard), [Wracky](https://opencollective.com/wracky),** and **[MiCroN3000](https://opencollective.com/micha-titulaer)**. 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](https://github.com/premake) or [@premakeapp](https://twitter.com/premakeapp).) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
--- | ||
title: "Community Update #4" | ||
tags: [community-updates] | ||
author: starkos | ||
author_url: https://github.com/starkos | ||
author_image_url: https://avatars.githubusercontent.com/u/249247?v=4 | ||
author_title: Premake Admin & Developer | ||
--- | ||
|
||
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](https://github.com/starkos/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](https://github.com/samsinsane) 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](https://twitter.com/premakeapp/status/1250780905016303616). Check out [Premake's recently closed PR list](https://github.com/premake/premake-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) for the details on how we got there. | ||
|
||
Whew! | ||
|
||
#### Alpha-15 | ||
|
||
With inbox zero reached, we also cut [a new 5.0 alpha release](https://github.com/premake/premake-core/releases/tag/v5.0.0-alpha15) with over 50 changes and fixes, from over 20 different contributors. Nicely done everyone, and thanks! 🙌 | ||
|
||
#### Premake5 Stable? | ||
|
||
Speaking of changes and releases, [#1423](https://github.com/premake/premake-core/issues/1423) from [@dvzrz](https://github.com/dvzrv) asks whether it's (finally) time to cut a stable release of Premake5. Fair question! As I responded on the issue, [@saminsane](https://github.com/samsinsane) 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](https://github.com/starkos/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](https://opencollective.com/premake), with an extra special 🎉 to new sponsors [Emilio Lopez](https://opencollective.com/emilio-lopez) and [Benjamin Schlotter](https://opencollective.com/benjamin-schlotter), and our stalwart benefactor **[CitizenFX Collective](https://opencollective.com/_fivem)**. 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](https://github.com/premake) or [@premakeapp](https://twitter.com/premakeapp).) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,110 @@ | ||
--- | ||
title: "Community Update #5" | ||
tags: [community-updates] | ||
author: starkos | ||
author_url: https://github.com/starkos | ||
author_image_url: https://avatars.githubusercontent.com/u/249247?v=4 | ||
author_title: Premake Admin & Developer | ||
--- | ||
|
||
### 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](https://github.com/starkos/premake-next/tree/master/core/modules/store). I threw [every edge case I could think of](https://github.com/starkos/premake-next/blob/master/core/modules/store/tests/test_query.lua) 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?) | ||
|
||
```lua | ||
-- 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. | ||
|
||
```lua | ||
-- 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. | ||
|
||
```lua | ||
-- 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. | ||
|
||
```lua | ||
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. | ||
|
||
```lua | ||
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: | ||
|
||
```lua | ||
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](https://twitter.com/premakeapp), email at **[email protected]**, or open an issue on [the premake-next GitHub project](https://github.com/starkos/premake-next). | ||
|
||
And as we do: a shout out to **[CitizenFX Collective](https://opencollective.com/_fivem)** and **[Industrious One](https://opencollective.com/industriousone)** and **[everyone else](https://opencollective.com/premake#section-contributors)** 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. |
Oops, something went wrong.