My take on sharing and centralizing configuration settings

[richard-sim]

Taking inspiration from the Premake docs (https://premake.github.io/docs/Sharing-Configuration-Settings/), I've come up with a structure that meets my goals of centralizing and simplifying project configuration (so it can easily be mix & matched in a single place) and not having projects need to know how to configure their dependencies (include dirs, defines, links).

Here's my playground repo:
https://github.com/richard-sim/build-sys-eval/tree/main/foobar/src

The important bits are the top-level premake5.lua file (obviously) then the per-project premake5.lua files are mostly very similar, but foobar/L2a/premake5.lua and foobar/L3a/premake5.lua are good examples to look at as they're a bit more involved and show how it all comes together.

I'm quite happy with the structure, but it is a long way from all the examples in the docs and that I see elsewhere around github, so I can't help but think that I may have headed down the wrong path. I'm new to Premake (well, I last used it something like 15 years ago, so...), so I'd love some feedback on it from those with more experience! The project premake5.lua files have more boilerplate/repetition between them than I'd like, but I'm not familiar enough with Lua to know of a good way to reduce that while keeping them flexible.

What should I do differently, what could be improved, or where may I run into problems? Are there any examples that achieve the same goals but in a more standard way?

[samsinsane]

Due to the flexibility that Premake provides, I would say there isn't really a "right way" to do things. I would do things differently to you, but our experiences are likely different so we prioritise different things.

What should I do differently, what could be improved, or where may I run into problems?

• I'm fairly certain that the includes you have in the project premake5.lua files are unnecessary as their contents have already been included.
• The functions for the projects are optional - check out how Premake does it:

  premake-core/premake5.lua

  Lines 279 to 291 in 9a70afe

  	group "contrib"
  	include "contrib/lua"
  	include "contrib/luashim"
  	if not _OPTIONS["no-zlib"] then
  	include "contrib/zlib"
  	include "contrib/libzip"
  	end
  	if not _OPTIONS["no-curl"] then
  	include "contrib/mbedtls"
  	include "contrib/curl"
  	end

• Path handling in Premake can be inconsistent with some APIs, so you may find it difficult to get the use_X functions to get paths right. Especially if any APIs are changed in the future to work differently.
• The boilerplate in use_X functions could be moved to a common base function that does:

function use_library(options)
  options = options or {}

  filter "kind:not StaticLib"
    links { options.libname }
  filter {}

  if options.staticFilter then
    filter { options.staticFilter }
      defines { options.libname .. "_STATIC" }
    filter {}
  end

  if options.sharedFilter then
    filter { options.sharedFilter }
      defines { options.libname .. "_SHARED" }
    filter {}
  end
end

-- Called like this:
use_library { libname = "L0a", staticFilter = depInfo.staticFilter, sharedFilter = depInfo.sharedFilter }

-- Or, you could have `use_library` take two arguments instead and do:
use_library("L0a", depInfo)

• You don't need to mimic the func {} pattern, you can use func() if you'd prefer. You may find using func {} makes it harder to know what is and isn't a Premake API, using func() might make it easier for you to keep track of.

There might be other suggestions I could make, but I think it's important for you to find your build scripts to be intuitive. At the end of the day, you will be the one that needs to read them, change them, and debug them.

[tritao]

• Path handling in Premake can be inconsistent with some APIs, so you may find it difficult to get the use_X functions to get paths right. Especially if any APIs are changed in the future to work differently.

Yep, this can be a bit painful, I end up having to pass relatie path locations to my use functions.

@richard-sim Here is a small example of how I am doing it, in case its useful as another data point.

local QUICKJS_DIR = "quickjs"

dependency {
    name = "quickjs",
    url = "https://github.com/quickjs-ng/quickjs.git",
    path = QUICKJS_DIR,
    revision = "ad834a144564955941d69a47da92dfb8c1dfa67f"
}

project "quickjs"
    kind "StaticLib"
    language "C"
    pic "On"

    defines {"_GNU_SOURCE"}

    files
    {
        path.join(QUICKJS_DIR, "cutils.*"),
        path.join(QUICKJS_DIR, "libbf.c"),
        path.join(QUICKJS_DIR, "libregexp.c"),
        path.join(QUICKJS_DIR, "libunicode.c"),
        path.join(QUICKJS_DIR, "quickjs.c"),
        path.join(QUICKJS_DIR, "quickjs-libc.c"),
    }

function use_quickjs(libs_dir)
    includedirs
    {
        path.join(libs_dir, QUICKJS_DIR),
    }

    filter { "not system:windows or emscripten" }
        links { "pthread" }

    links { "dl" }

    links { "quickjs" }
end

I track all my source and binary dependencies in Premake and have a simple task system where I can define tasks, for example update which updates my dependencies to their latest versions.