How is includeexternal supposed to work?

[Sairony]

It would seem to suffer from a lot of edge cases & very little error reporting. If the file included has a workspace of its own there's no error & you end up with an empty work space. We have a master file which goes through a project sub folder looking for premake.lua files. If it finds one it's run with dofile(), these in themselves can have a workspace and reference other premake files from which they want to reference projects. I've found no setup which can easily generate a master workspace with all projects, and workspaces which references these projects. It would be sweet if projects could have multiple workspace parents instead of trying to process the files multiple times & getting the external tags working.

[WorldofBay]

what do you mean with a master workspace? if you want to group your projects inside a workspace, then you can do this via groups.

if you need multiple workspaces and a way to put them all in one big workspace without much effort you can replace all your workspace literal inputs with variables that test for your master workspace run:

local myWorkspace = masterWorkspace or "myWorkspace"
workspace(myWorkspace)
-- projects in myWorkspace

then in your master file you got a call like

if _OPTION["master-workspace"] then
  masterWorkspace = "masterWorkspace"
end

[Sairony]

I mean a workspace which when built will build everything in the repository, containing all possible permutations. Setting up continuous integration is easier & overall it's a good place to get an overview of everything. On the other hand developers would usually use a much more constrained workspace just containing the particular project & its dependencies which they are working on.

In any case I think this problem stems from the fact that premake presumes a tree structure, when in reality it's actually a graph. A project should be able to contain more than 1 parent workspace, and the deal with includeexternal is more or less a workaround for this fact. My understanding is that you can end up with several project objects, which in fact are the same ( the only one that gets generated is the one which isn't marked as external I presume? ). It's still possible to modify the projects marked external, but in the end everything which is project specific would probably not matter because they merely serve as a placeholder right?

I hacked together a low quality implementation of importproject a year ago here which didn't use external. importproject here accepts either a "workspace/project" string to deal with the fact that referenced project might not yet be available ( due to order of premake.lua parsing ), or a project lua object. It doesn't need to do a lua file more than once and I find it to be a easier & more intuitive way to work with.

Ideally I'd not want to use the master workspace for everyday coding, since it will contain to many projects & to many files to index for visual assist, otherwise the group approach would be nice! I'll tinker some with the string override approach, thanks :)

[WorldofBay]

ah ok i understand it now :)

for a quick fix the string override should be the best way, the clean way most likely includes extracting the workspace calls into separate lua files that then call their projects via require/dofile.

since you want all of your projects imo the includeexternals approach is no more than a quick fix either - it has the same flaws as the string thing: everyone who adds a new projects needs to remember that workflow (even worse: the string version is copied when a project is copied, the includeexternals not). with separate files for workspaces and projects a new project is automatically added to the master workspace just by being there.