moomalade/premake-usage

[starkos]

While responding to a recent issue, I (re-)discovered Tim Wharton's usage module. Has anyone had a chance to use this in a production setting? Is it at a place where it could be moved into core to get more visibility?

https://github.com/moomalade/premake-usage

–st.

[Tom van Dijck]

At Blizzard we're using the "Export" module (https://github.com/Meoo/premake-export) in production, although in limited cases.

It's the same concept, a little more complicated, and it has it's flaws... the 'virtualproject' concept in that module however is pretty cool.

All that said, just a cursory review of premake-usage:

- The logic to split fields between 'link' and 'common' seems arbitrary, and certainly not complete, I would rather see this explicitly exposed as "linkusage" and "compileusage", so I can control what goes where as a user, also link and compile are not the only stages of a build... there is prebuild, postbuild, postlink, as well as binary dependencies such as utilities used to compile shaders, and what not. explicit usage api's for such passes would be helpful, in particular the tools dependency is something we use a lot.

It is briefly considered in the comments, although only at the tail end, which in my opinion is less important:

https://github.com/moomalade/premake-usage/blob/master/usage.lua#L47

- There is no tests... neither does the Export package, which in my book somewhat rules them out for inclusion in premake core. 

Certainly for the part where the code makes an attempt at merging criteria blocks when applying them into the project. That is such a complicated code-path that without tests I wouldn't trust it to work. 

- There is a set of todo's in the code, which we need to understand and maybe resolve.

- At Blizzard we modified the "Export" module to also allow the export of settings from rules... any project using the rule gets those settings applied.. Again very useful for tool dependencies. 

Something I'd like to see work for the usage* APIas well.

- Cyclic references:

https://github.com/moomalade/premake-usage/blob/master/usage.lua#L78

This is absolutely a breaking point for Starcraft.. While I completely agree that cyclic references are bad, and I would love to live in a world where we didn't have them, the reality is that we do. 

Utilities like this need a solution.

- https://github.com/moomalade/premake-usage/blob/master/usage.lua#L104

I'm not sure I understand the comment.

- https://github.com/moomalade/premake-usage/blob/master/usage.lua#L423

I like that approach, good idea... however... "StaticLib" isn't the only one to exclude, what about Utility, None, etc... 

I'd rather see this be an inclusive filter on WindowedApp, ConsoleApp and SharedLib.