Pacific, WWII and War

Last week, I binge watched the Pacific on hotstar. Once I realized that the series is heavily inspired by the book With the Old Breed: At Peleliu and Okinawa, I obsessively read the book as well. I am a defence and aviation enthusiast, so I keep watching these shows and read a lot of books.

The TV Show has a lot of gore. Limbs falling off, soldiers dying left and right, living and fighting around the dead bodies of other soldiers. All this gore is probably real – this is how war really is.

The gore does not become very apparent in the book, but it does capture the fears, the physical and psychological hardships and trauma that a soldier has to endure.

Surviving even a single campaign is hard. If my understanding is right, the war planners planned for attrition rates of 1/3 in the Pacific theatre and as much as 1/2 in some campaigns and scenarios. That’s a lot of wounded and killed.

The life of a soldier is hard. It’s hard for any of us to look at the kind of gore they face – not just the enemy but own friends, civilians – including children. If you think about modern protracted wars – Iraq, Afghanistan, Sri Lanka, Kashmir, North East of India – these would definitely be hard and have a dehumanizing effect on the soldiers and combatants. That just makes things worse.

Understandably, the trauma and brutalization faced by non-combatant civilians who live in such areas is going to be just as bad, if not worse.

Wars should end swiftly. They are not worth dragging. Wishful thinking maybe.

Living with Premake

When you are working with cross-platform code, ensuring that your build-system is cross-platform too simplifies things quite a bit.

While there are more sophisticated build systems, I love premake for its simplicity. Though getting some things done can be quite a challenge. In this post I will briefly talk about some tricks and hacks that I have used.

There might be better ways of doing these things and I would be more than happy to learn about them.

Project Sub-modules

This is with premake 4.4. For a project that requires the ability to selectively choose what went into the build – include sources and components that have to be removed/added according to what has to be deployed – we wrote wrappers to our premake scripts that used these methods:

function appendToTable(t1, t2)
for k,v in ipairs(t2) do
table.insert(t1, v)
return t1
function initSoln(solnname, corepath, variant)
solnname.srcfiles = {}
solnname.includepaths = {}
solnname.linklibs = {}
solnname.libdirpaths = {}
solnname.buildoptions = {}
— paths you would want all modules to have
common_includepaths = { corepath .. "path1",
function addCompToSoln(solnname, comppath)
compfile = comppath .. "/premake4.lua"
default_path = comppath
appendToTable(solnname.srcfiles, default.srcfiles)
appendToTable(solnname.includepaths, default.includepaths)
appendToTable(solnname.linklibs, default.linklibs)
appendToTable(solnname.libdirpaths, default.libdirpaths)
appendToTable(solnname.buildoptions, default.buildoptions)

view raw
hosted with ❤ by GitHub

This could be extended to copy source files to a global destination, magic for selecting sources to be included in the build etc. Now, the module implementation would look like this:

module = {}
module.srcfiles = { module_path .. "/src/file1.c" ,
module_path .. "/src/file2.c"
ppcast_core_controller.includepaths = { module_path .. "/inc/" }
ppcast_core_controller.linklibs = { }

view raw
hosted with ❤ by GitHub

And you would put together the build by doing something like this in our top-level scripts:

the script containing our util functions
soln ={}
initSoln(soln, soln_path, "windows")
addCompToSoln(mod, mod_path)
anything else you want to add from this file
appendToTable(mod.includepaths, includedirset)
appendToTable(mod.linklibs, includelibset)
appendToTable(mod.libdirpaths, includelibdirset)
project "soln"
language "C"
kind "SharedLib"
files (mood.srcfiles)
includedirs (mod.includepaths)
location "build"
links (mod.linklibs)
libdirs (mod.libdirpaths)
buildoptions (mod.buildoptions)

view raw
hosted with ❤ by GitHub

Building with modules like this is also very convenient for hiding away code and blobs you don’t want to distribute or want others to know that exist. There might be simpler ways to do something like this using filters, defines etc but this was something straightforward that I liked to use.

VS2012 to VS2013

Premake 4.4 only had VS2012 support – no VS2013. In case you want to go from 2012 to 2013 – upgrade to premake5 (and that happens to be a solution for a lot of problems). If you can’t, here’s a non-premake hack:

Now, if you simply change all references to the older version of Visual Studio in the .vcxproj file, you will have something that works:

..\utils\gsar.exe -s"4.0" -r"12.0" build\myproject.vcxproj build\myproject.vcxproj.1
..\utils\gsar.exe -s"v110" -r"v120" -f build\myproject.vcxproj.1 build\myproject.vcxproj
del build\myproject.vcxproj.1

view raw
hosted with ❤ by GitHub

I used the windows build of gsar.exe.

Moving to the awesome premake5 + VS2015

So upgrading to premake5 isn’t going to require much effort… and when you are upgrading, might as well upgrade the toolchain. While upgrading, this is all I had to take care:

– premake configures the entrypoint function to int main(), even for UNICODE projects. So fix that.

– link to legacy_stdio_definitions for a whole bunch of CRT linker issues.

AND… thats about it. Everything else was a breeze.