Investigate what's required to commit this project to premake5 upstream

[jimon]

So https://github.com/premake/premake-core/issues/141 is closed. Would be nice to actually commit this to upstream so it would be maintained more properly.

Honestly premake5's make action is not that complicated, so this one shouldn't be that hard either. Some topics to think about :

• Migrate to premake5 tests.
• Compliance with C#/D/etc.
• Just take premake5 make action and slightly modify it to generate ninja syntax? ninja and make operate on similar concepts, so shouldn't be that hard.

[TurkeyMan]

I'd love to see ninja as first-class premake output, but there's a lot of work to do here. The tests should use premake test infrastructure, as discussed, and there appears to be a lot this module doesn't do. The code isn't very modular or hack-able; all in one file. It might be nice to define it in terms of 'rules', allow for the custom rules api's, which are very important to premake, and also express the default C/C++/C#/etc builds as builtin rules. I suspect that it might be less work to transform the existing gmake code into a ninja writer. There might even be a lot of code sharing between them (ie, high-level rule definition, code that generates command lines, etc.)

[jimon]

@TurkeyMan yes, would be indeed nice to make it first-class citizen. But I had to abandon attempts because premake test infrastructure makes no sense for me :( To be able to add a new output target to premake, I need to be able to verify that all premake features are correctly working (like custom commands, platform specific stuff, etc) for new output.

Back when I was researching it in 2016 it was obvious that premake had close to zero end-to-end tests, no test suite, nothing (there is unittest level test suite, but this doesn't verify that end user will be able to compile stuff). The only way to test that actual compilation of a source file worked is to do it yourself (which is done in this repo). I don't want to trust "just works" approach, as it requires a lot of manual testing, and not future proof.

Because of this reasons I had to stop using premake, and unfortunately switched to cmake.

[TurkeyMan]

Haha, okay. Fair enough. I'm not so sure the words 'had' to stop using premake are quite factually correct ;) ... But I understand you might have been compelled to cmake. That said, Why didn't you just submit your own end-to-end test infrastructure to premake? If you feel the test system was insufficient, and it could easily be better... then I think you'll find contributors will (do) share that opinion.

[Jarod42]

because premake test infrastructure makes no sense for me :(

@jimon : It might be useful for some stuff, but indeed, is not adapted for multi-generators. So I created https://github.com/Jarod42/premake-sample-projects to test with sample projects with different generators. With just some basic stuff, I found bugs in some generators (and fix some). I am just adding your generator (and fixes some issues) (in dedicated branch until it passes my tests).

[Jarod42]

Ok, I fixed some stuff in premake-ninja, so now all my tests passes successfully :-)

I still try to promote those tests instead of the ones from premake which are mostly useless for generator :-/ (they consider mines too hard to maintain :-( (whereas mine are shared accros generators without extra costs and already spot issues for each (non-main (msvc/gmake)) generators)).

[Jarod42]

Asked question to know what are prerequires to be in core:

https://github.com/premake/premake-core/discussions/1689