split dflaunch into separate project

[ab9rf]

Building dflaunch (with the Steam SDK) is proving to be tendentious (mainly due to the need to download the Steam SDK since we can't store it in the public repo).

Instead of building this each time we do a Steam deploy, what I'd like to do is split dflaunch into its own deploy, and only rebuild it when it changes (which should be much less frequent than for Steam deploys in general) and have the Steam deploy workflow in the main project simply copy the last good build artifacts (which for now is just launchdf.exe and steam_api64.dll, but this may grow if and when we get native builds for Linux or Mac) from the side project.

[lethosor]

This seems reasonable to me. Do we expect dflaunch to need any core DFHack code?

[ab9rf]

We've determined that the Steam API has a "there can be only one" attitude about app IDs (that state is per-process, not per-thread) and so if we want to talk to Steam as DFHack and not as DF, we have to do it in a separate process. Since we're forced to have two processes, any access to the DFHack core from the launcher (acting as a Steam API proxy), or to the launcher from the DFHack core, would be via some sort of API specification that we'd have to develop.

This also means that the Steam API itself will stay out of the DFHack core; any Steam API functionality will be proxied (presumably within the DFSteam module).

[lethosor]

My question is really about project organization - specifically, would dflaunch need to pull in any existing DFHack code at build time? I doubt it, but if it does, sharing a repo might make sense. For instance, dfhack-run is a standalone executable that pulls in MiscUtils, ColorText, and a few other bits.

[ab9rf]

we need somewhere to stash the build artifact, not sure where we can do this persistently within the github infrastructure other than as a release artifact which requires a separate repository

[myk002]

We have traditionally used https://github.com/DFHack/dfhack-bin/releases for this. The built launchdf might fit in there too.

[lethosor]

I think a separate repo makes sense if we are talking about releasing artifacts. Making new dfhack-bin releases is a somewhat tedious process with all the artifacts it involves.

Still, my only question here was whether we expect to need DFHack code in the dflaunch project. If we don't, I am entirely in favor of a separate repo. If we think we might need some, my suggestion is to minimize those dependencies as much as possible.

[ab9rf]

I think a separate repo makes sense if we are talking about releasing artifacts. Making new dfhack-bin releases is a somewhat tedious process with all the artifacts it involves.

Still, my only question here was whether we expect to need DFHack code in the dflaunch project. If we don't, I am entirely in favor of a separate repo. If we think we might need some, my suggestion is to minimize those dependencies as much as possible.

the only shared code i can imagine would arise would be if we ever want to provide an api to access the Steam API via DFHack's appid, which has to be done via the dflaunch procese because the steam API implementation uses a global per-process singleton and thus any use of the Steam API in the DF process will use DF's (and not DFHack's) appid. if this is ever wanted, we'd have to define a proxy RPC API to allow DFHack (running in DF's process with DF's appid) to talk to dflaunch (running in its own process with DFHack's appid), which would have to be shared between dflaunch and dfhack

otherwise, i really don't see any likelihood of any hard dependencies, given the requirement (forced by the Steam API) that dflaunch has to run in a separate process

the dflaunch artifact is required for steam deploys, since we have to include it in the steam build for it to be considered an "application". its only plausible use would be to be bundled into steampipe deployment manifests (especially since it's largely useless if you don't have the steam client installed)