This is my human-readable effect file. Simple enough, it indicates path for vertex shader and fragment shader in a key-value pair pattern. There's no special reason for such a design but simple enough as well as fulfill user requirements for now. This may face redesign in future.

This is my binary effect file. As we can observe, it simply contains two strings which represent name for binary vertex/index shader separately. And after each string, an '\0' is added to indicate string end. This is used when reading strings from buffer. At run time, the first string is get by std::string(buffer). std::string ctor will automatically truncate string at first '\0' it meets. Then the beginning index of the second string is got by offset = strlen(FIRST_STRING) + 1. Do another std::string(buffer + offset) will get the second string.

I choose to use one builder for both shaders as JP did. Optional arguments will be practical for many builders so it's a capable candidate to add to AssetToBuild file. I would consider slightly increasing in build time acceptable compared to duplicate code. For assets need optional arguments to build, structure looks like this:

{
    Tool = "ShaderBuilder.exe",
    Assets =
    {
        "lininterpvertex.shader",
    },
    Optional =
    {
        "vertex",
    }
}

Other assets look like this:

{
    Tool = "EffectBuilder.exe",
    Assets =
    {
        "default.effect",
    }
}

The reason for having custom defined macro for shader is to make it more flexible. We can have different sets of defined settings such as having a logo version and a no-logo version but both with debugging enabled.

Above 2 figures are debug vs release version of d3d vertex shader. Release version is much shorter than debug version. This is because we pass in an allowing optimizing argument for release version. It's the shortest possible but containing all info.

Above 2 figures are debug vs release version of gl vertex shader. Release version is slightly shorter only because it gets rid of newline character in the file. It's reasonable to do so in a release build because we need less readability on release version, while we need to see a better line-divided organizing file while debugging.

Here's a copy of my executable