dcourtois / premake-qt

Premake module adding support for Qt to actions (Visual Studio, makefiles, etc.)
Do What The F*ck You Want To Public License
45 stars 11 forks source link

Update path APIs to resolve tokens #17

Closed mikeeheler closed 4 years ago

mikeeheler commented 4 years ago

This change allows qtpath, qtbinpath, et al, to include tokens which can be useful in cases where the Premake context is important in determining those paths.

For example, the Qt SDK Installer installs each platform SDK to, say, <qt-install-dir>/<qt-version>/msvc2019_64. The information contained in premake's cfg object can be used to determine that at bake time, but it must be resolved as a token:

qtpath '%{getQtSdkDir(cfg)}'

Where getQtSdkDir(cfg) is a function in the global scope that can translate the context into the correct Qt SDK path.

While one could set QTDIR before running premake, this doesn't behave well with multi-arch Visual Studio workspaces, or when a custom build of the Qt SDK places shared/static runtime and debug/release builds into separate paths.

dcourtois commented 4 years ago

Hi,

I don't really understand what you want to achieve with this PR ? qtpath and qtincludepath, etc. already allow you to specify all paths per-configuration, so you could have multiple platforms in the same VS project mixed-in with multiple configuration (statically linked, dynamic, debug build, etc.)

Mind explaining a bit more precisely the problem you're having, which you're trying to solve with this PR ?

dcourtois commented 4 years ago

(I'll merge the PR by the way, I'm just curious why the need for tokens :p)

mikeeheler commented 4 years ago

Heya! So my specific use case is resolving a path for shared custom builds of Qt that include information such as architecture and build config name. It may be my inexperience with Premake, but this specific change is how I got there. For example:

\\fileserver\qtbuilds\5.15.0\windows-vs2019-x86_64-dll-release
\\fileserver\qtbuilds\5.15.0\windows-vs2019-x86-static-debug

The only way I could find to reliably switch up the qtpath based on architecture, runtime, and config was with a token:

function getBuildName(cfg)
    local runtime = cfg.staticruntime ? 'static' : 'dll'
    return cfg.system .. '-' .. _ACTION .. '-' .. cfg.architecture .. '-' .. runtime .. '-' .. cfg.buildcfg
end
-- later, in a workspace with, say, a 2x2 config matrix of x86/x86_64 and staticruntime on/off:
qtpath('\\\\fileserver\\qtbuilds\\5.15.0\\%{getBuildName(cfg)}')
premake.extensions.qt.enable()
dcourtois commented 4 years ago

Ok I see now, it could probably be solved with filter but the code would have been a lot messier to handle all the combinations.

mikeeheler commented 4 years ago

Yeah, exactly.

dcourtois commented 4 years ago

Merged, thanks for the pull request!