The Machinery - Part 2

Using the environment

In the previous post I mentioned how I found it annoying that everytime I built something, a lib folder with redundant copies of premake and 7zip were being downloaded. After mentioning this on the forums, Niklas clarified that using the TM_LIB_DIR will solve this problem for you.

tmbuild expects you to have defined the environment variable TM_SDK_DIR already and rather than set environment vars globally like this I tend to use a convention of having a .env or .env.bat file in the root of a project or repo. So in this case my env setup looks like:

set TM_SDK_DIR=%cd%\OurMachinery
set TM_LIB_DIR=%cd%\OurMachinery\lib

set PATH=%TM_SDK_DIR%\bin;%PATH%

When I want to work on slowgames related stuff (that isn't using UE4 or something similarly self-contained), I source my env:

call .env.bat

or on a posix-ish platform:

source .env

Then I run whatever editor or IDE I'm planning to use. Presently it's been VS Code since it seems like the least effort to get working.

I also enquired about the clang format setup being used by Our Machinery on the forums. The defaults for VS Code were wildy different. A helpful user shared their setup based on something provided on the Discord server and I modified it ever so slightly. If you'd like to see it, then here ya go.

Organizing the workspace, choosing an approach

With that sorted out I want to decide how to actually structure any experiments.

As I mentioned in the previous post, plugins are apparently expected all be loaded from $(TM_SDK_DIR)/bin/plugins and so far every premake script in the samples and SDK set that as the output directory.

Is this the only place The Machinery can load plugins from? If so, then is it expected that any projects using The Machinery should vendor the SDK as part of the project?

The answer is that, yes currently for the beta this is the case, however there are plans to have project specific plugin locations in the future so it doesn't appear to be expected that you'd be vendoring the SDK into every project.

So how to proceed? What sort of layout and workflow isn't going to trigger an itch?

If you're like me, then there probably isn't much that won't make you itch a bit. So I decided initially to just make a top-level premake script and duplicate any other bits of the SDK or sample projects I wanted to refer to so that even if I decided to use Visual Studio instead of VS Code I'd have something handy to reference. Very soon after creating a new plugin project and setting that up, I realized what a mistake it was. :)

Instead I just decided to make a project level premake script, accept that the output will go into the SDK for now, and not worry about having potential reference projects included in the Visual Studio solution.

So in my repo I have a project folder, with a plugins subdirectory. In the project is a premake script which will define targets for any plugins. This approach is based on how the SDK samples project is setup as opposed to how the sample_projects setup is to have a premake script on a per-plugin basis.

Any confusion early on regarding how you're supposed to do anything is largely the result of The Machinery being like a nice box of Lego instead of a set of choices followed by bumper rails to lead you to a set of pre-defined targets. You can do whatever you like and it'll probably be ok.

To quickly summarize, my project root now looks like:

c:\projects\slowgames\CosmicTrash>fd
Slowgames.sln
libs.json
plugins
plugins\sprite_component
plugins\sprite_component\sprite_component.c
premake5.lua

sprite_component is just a sample component created via the editor. For the curious, the output from tmbuild in project folder:

c:\projects\slowgames\CosmicTrash>tmbuild -c Release
Building configurations...
Running action 'vs2019'...
Generated build/sprite_component/sprite_component.vcxproj...
Done (169ms).
Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  sprite_component.c
     Creating library c:\projects\slowgames\OurMachinery\bin\plugins\tm_sprite_component.lib and object c:\projects\slowgames\OurMachinery\bin\plugins\tm_sprite_component.exp
  sprite_component.vcxproj -> c:\projects\slowgames\OurMachinery\bin\plugins\tm_sprite_component.dll

-----------------------------
tmbuild completed in: 6.269 s

And now in the next post we can finally start looking at code.