Closed bux closed 4 years ago
Basically what we do in ACE3/CBA/ACRE2 (but more expansive due to templating), we call them "version files". Could simply have an entry and run templating on them during builds.
Could also split dev and release builds, eg. {git-commit|version}
(dev-<git-hash>
for dev builds, version
for release builds).
We could maybe do something where you prepend an extension. so mod.cpp
would be mod.t.cpp
. HEMTT would then process that file with our handlebars templater. This would prevent any unintentional changes.
Or add a new section to the config for those files.
I'd like to get some more opinions, I might bring it up in the ACE slack.
I personally like mod.t.cpp
because it is immediately obvious that it will be templated, and prevents people that are working on a large project like ACE that might be unfamiliar with HEMTT from having to ask why it is or isn't happening. Especially if building is abstracted through a build.bat
, some people might not even be aware of a HEMTT project file.
Adding such a file would create an obvious dependency on a build system. That's why - imho - I'd prefer a config rather than artificially introducing new file types.
Any solution requires an external build system since some program will be needed to actually do the templating, HEMTT or otherwise. HEMTT is trying to be a better alternative to solutions like make.py that ACE has. Using mod.t.cpp
wouldn't be another dependency, it would be replacing the existing one.
If it was only going to be strings mod.cpp
would probably be fine since a regular build would work fine, albeit without the templating. Having My Mod - {{version}}
in a local build isn't an issue. However there is no reason it couldn't be numbers, or even externally generated structures. Having version = {{version}};
in a config file would not work.
Any solution requires an external build system since some program will be needed to actually do the templating, HEMTT or otherwise
wouldn't be another dependency
Assuming you'd then only keep a mod.t.cpp
file in your repository you've created a dependency on a build system. Having just a mod.cpp
file you could even start Arma and load that mod because it would just work albeit the output would contain the placeholder {{xxx}}
strings.
Having version = {{version}};` in a config file would not work
Why would that be in the config? In my head there's no difference between pointing hemtt to files that need string replacement by using a special name *.t.*
or having a list of those files in the config.
files: [
"mod.cpp",
"Readme.md",
"..."
]
Beforehand one would need to agree upon what can be replaced and how the placeholders need to be named for hemtt to replace the files.
Or am I overlooking something here?
Why would that be in the config?
version = {{version}};
is what HEMTT would use for templating. If mod.cpp
was used and someone built the addon using a different tool like PboProject, that would result in version = {{version}};
being included, and breaking the config file.
When I was first learning Arma 3 modding projects like CBA and ACE served as a great resource for learning standards, I was not as aware of the python build scripts. Using mod.t.cpp
makes it more obvious to developers of the project and people using the project as a reference that tooling is being used on that file. It also prevents files from being accidentally included or omitted from the HEMTT project file.
Ok, when you say "config" you seem to mean the mod.cpp file!?
I was referring to the "hemtt.json" configuration file.
Ah, yes. I was referring to any Arma 3 configuration. mod.cpp
and *.hpp
Is this implemented? The docs dont talk about it
HEMTT Version:
0.5.1
(stable)As a user I would like to use version placeholders in my mod.cpp file that get replaced with the mod's version to show the mod's version in the Arma 3 ingame mod list.
Example:
Given a mod.cpp of:
Would result in: