Linux: Consider forking premake, fix up known issues, and rebrand under LTS middleware or here #4

New Issue

reece · 2022-05-15T14:58:16Z

reece commented

2022-05-15 14:58:16 +00:00

Some sources:
https://github.com/premake/premake-core/pull/1852 (dumb hypocrisy. you need look no further than the latest commit to see him merging similar patches, literally the exact same p.esc shit, of 2 lines instead of 3. c36e48a10e)
https://github.com/premake/premake-core/issues/479 (the degree to whch they actually care about resolving and mitigating issues)
https://github.com/premake/premake-core/commits?author=samsinsane (worthless contributors with write power running the show)
https://github.com/premake/premake-core/issues (205 issues open - this isnt sustainable for a relatively small and decade old project thats had plenty of time to keep up)
https://gitea.reece.sx/AuroraPipeline/Build/src/branch/master/Core/project.lua#L268 (here's just one premake bug i wrangled in here without commenting on its existence)
https://github.com/starkos/premake-next (the future of premake - an official soultion to things i've already hacked around with no sign of any real performance improvements that havent already been merged with 5. not really filling me with much confidence)

My stance:
[14:24] reece: what has your experience been like with the premake devs?
[14:25] reece: thinking about saying fuck them and forking
[14:26] reece: there are plenty of issues that i'm aware of in the project bc those dumbasses don't bother end-to-end testing anything, and yet they demand new contributors to write redundant tests in frameworks they dont understand before fixing genuine issues
[14:27] reece: like for instance, gmake is heavily updated, and the core "tests" (pretty much if contains or something, cant tell) havent really been updated since they merged blizzards branch. not only havent they tested and fuzzed the core of these backends, they dont even bother testing most of their own damn changes
[14:28] reece: there's a risc gta thing that wasn't closed bc of this
[14:28] reece: plenty of unattended prs
[14:29] reece: plenty of tokens are scuffed when resolved for post/pre buildcommands
[14:29] reece: $ and other characters aren't escaped properly
[14:29] reece: tons of cancer bc they clearly dont test in a meaningful manor
[14:29] reece: github ci addicts and their "tests" basically
[14:33] reece: genie is too old and premake could be a hell of a lot better
[...something not necessarily positive about the people running the project by what was a significant donor of their project]

premake contributors are larping idiots with no sign of starkos

The future of scriptable build pipelines should be brighter than shipping """portable""" python as a solution, and brighter than premake contributors.

Some sources: https://github.com/premake/premake-core/pull/1852 (dumb hypocrisy. you need look no further than the latest commit to see him merging similar patches, literally the exact same p.esc shit, of 2 lines instead of 3. https://github.com/premake/premake-core/commit/c36e48a10e6c2c69624ec51c44ab51167bf65fd3) https://github.com/premake/premake-core/issues/479 (the degree to whch they actually care about resolving and mitigating issues) https://github.com/premake/premake-core/commits?author=samsinsane (worthless contributors with write power running the show) https://github.com/premake/premake-core/issues (205 issues open - this isnt sustainable for a relatively small and decade old project thats had plenty of time to keep up) https://gitea.reece.sx/AuroraPipeline/Build/src/branch/master/Core/project.lua#L268 (here's just one premake bug i wrangled in here without commenting on its existence) https://github.com/starkos/premake-next (the future of premake - an official soultion to things i've already hacked around with no sign of any real performance improvements that havent already been merged with 5. not really filling me with much confidence) My stance: [14:24] reece: what has your experience been like with the premake devs? [14:25] reece: thinking about saying fuck them and forking [14:26] reece: there are plenty of issues that i'm aware of in the project bc those dumbasses don't bother end-to-end testing anything, and yet they demand new contributors to write redundant tests in frameworks they dont understand before fixing genuine issues [14:27] reece: like for instance, gmake is heavily updated, and the core "tests" (pretty much if contains or something, cant tell) havent really been updated since they merged blizzards branch. not only havent they tested and fuzzed the core of these backends, they dont even bother testing most of their own damn changes [14:28] reece: there's a risc gta thing that wasn't closed bc of this [14:28] reece: plenty of unattended prs [14:29] reece: plenty of tokens are scuffed when resolved for post/pre buildcommands [14:29] reece: $ and other characters aren't escaped properly [14:29] reece: tons of cancer bc they clearly dont test in a meaningful manor [14:29] reece: github ci addicts and their "tests" basically [14:33] reece: genie is too old and premake could be a hell of a lot better [...something not necessarily positive about the people running the project by what was a significant donor of their project] premake contributors are larping idiots with no sign of starkos The future of scriptable build pipelines should be brighter than shipping """portable""" python as a solution, and brighter than premake contributors.

reece changed title from ~~Consider forking premake, rebrand, fix up known issues, and rebrand~~ to Consider forking premake, rebrand, fix up known issues, and rebrand under LTS middleware or here

2022-05-15 14:58:25 +00:00

reece changed title from ~~Consider forking premake, rebrand, fix up known issues, and rebrand under LTS middleware or here~~ to Linux: Consider forking premake, rebrand, fix up known issues, and rebrand under LTS middleware or here

2022-05-15 14:59:44 +00:00

reece changed title from ~~Linux: Consider forking premake, rebrand, fix up known issues, and rebrand under LTS middleware or here~~ to Linux: Consider forking premake, fix up known issues, and rebrand under LTS middleware or here

2022-05-15 15:02:06 +00:00

reece closed this issue

2022-05-15 15:49:01 +00:00

reece reopened this issue

2022-05-15 15:49:06 +00:00

reece commented

2022-07-19 15:59:40 +00:00

Multithreaded / shared cfgset seems plausible. The entirety of the long stall time is spent baking im sure we could delegate to worker threads. xmake doesnt look too bad either. Could shim that in?