Workspace / project file structuring.

[lolrobbe2]

when working on premake manager i realised it would be better to put all the common parts like version management, module management, project/ workspace management in a nice looking CLI tool premake manager cli.

The idea is that other extension like vspremake can integrate it.

This keeps things uniform to and keeps it organised in one tool.

The end goal is to also add this CLI tool to packagemanagers.

The workspace generator.

now the Question is how to format the workspaces that will be generated with their projects.

options (i can think of!)

• put all in the premake5.lua
• per workspace a file with the filename: workspace.lua (containing the projects)
• keep the workspace file in the folder of said workspace and have seperate project.lua files each at the defined project location
  these are then bound in the premake5.lua file.

What do you think is best? @samsinsane, @Jarod42, @nickclark2016

[tritao]

Definitely agree that we need a solution to this. However I disagree this should be provided by an external CLI tool (developed in C#, no less, a language which I am a fan to be clear).

This kind of functionality should be provided by Premake itself with no extra dependencies IMHO, if not by core, then by an extension. I have developed my own system based on Premake itself that does a subset of this (actions, with action dependencies system) which I can share, not sure if its fully functional for everything you list, but can be at least a source of inspiration.

I'd be down to collaborate on it if you'd like.

[lolrobbe2]

@tritao it would be better if this is in premake itself (module management) but the CLI tool is also there in preperation to work with the module registry i am working on. (wich is not part of premake at the moment).

The other reason for the CLI tool was to keep things seperated.

[tritao]

I still don't see why a separate CLI tool is needed for that, why not do it all in Premake and Lua? I think Premake already supports APIs that are needed for it (zip and http).

[lolrobbe2]

the reason why not all of this can be done in premake is because of Octokit.
wich allows a clean interface with the github api.
wich is used for the following:

1. retrieving version information (premake,modules)
2. retrieving module information
3. when the github api is changed on the background Octokit api stays mostly the same.
4. the github api uses rest and JSON (wich would mean we would have to add a JSON parser)

[tritao]

the reason why not all of this can be done in premake is because of Octokit. wich allows a clean interface with the github api. wich is used for the following:

1. retrieving version information (premake,modules)
2. retrieving module information
3. when the github api is changed on the background Octokit api stays mostly the same.
4. the github api uses rest and JSON (wich would mean we would have to add a JSON parser)

I'm not sure why Octokit API is necessary, seems like just downloading a single file as HTTP request from a Github repo should be enough. As for JSON, I have proposed in the past to add https://github.com/mpx/lua-cjson to Premake, but it was suggested to just use a Lua JSON parser, and that is easy enough to add to Premake. Not even JSON is needed, as we can also publish a say registry.lua file for direct evaluation with Lua (properly sandboxed). JSON is simple enough to add though if preferred.

[Jarod42]

Unclear to me if those scripts are generated by your tool, or if your tool expects some hierarchy...

options (i can think of!)

It seems mostly style and opinion-based...

• put all in the premake5.lua

It is the one I used on my projects.

• per workspace a file with the filename: workspace.lua (containing the projects)
• keep the workspace file in the folder of said workspace and have separate project.lua files each at the defined project location
  these are then bound in the premake5.lua file.

Those are viable too,
it allows smaller (sub-)scripts, possibly reusable (assuming compatible configurations)
Care has to be done with relative paths though (usage should fix some, but pre/post buildcommands and functions might have issues).

[Jarod42]

Managing the different version of premake seems unrelated to the directory structure.

As I understand, it does also some packaging management, which would be more related to the structure, but only the main one seems relevant.
Adding an extra layer on your side might allow to unify your code to be more independent of the "package"...

[lolrobbe2]

@Jarod42 What do you mean extactly with: Adding an extra layer on your side might allow to unify your code to be more independent of the "package"...

like this where i have a premakeModule.yml with general module info etc.

[Jarod42]

Yes entrypoint seems to do the job, making that question obsolete IMO.
BTW, typo: "description"

discription: "enable the use of KCONFIG files with premake"

[lolrobbe2]

Managing the different version of premake seems unrelated to the directory structure.
it is but this CLI tool is also meant as a common interface for extensions to hook into.
it was just meant as a visual representation of how it works more or less

[lolrobbe2]

Yes entrypoint seems to do the job, making that question obsolete IMO. BTW, typo: "description"

discription: "enable the use of KCONFIG files with premake"

Thanks for the typo spotting

[lolrobbe2]

• The C# application is compiled as a single file for future reference.
• The path variable is automaticly set when setting the version.
• Premake is installed in the following location.
  windows: Application data roaming folder.
  unix: usr/lib/bin and then uses a symlink with usr/local/bin