Build Logic Classes

[Rune-Magic]

This adds build logic classes as described in #2403, progress:

• prebuild and post build code runs
• console output
• debugging support
  dynamically add additional lib paths from build logic

[Rune-Magic]

debugging via Build > Debug Comptime now works

[Rune-Magic]

comptime output added through Compile.Write[Line]

[Rune-Magic]

comtime output is now added via Console.Write[Line] instead of a comptime specific function

[Rune-Magic]

added Console.RunShellCommand, this is more convenient for build script than spawning process. plus it outputs directly to the ide output window, instead of spawning a command prompt in your face

[Rune-Magic]

I was able to get Environment.[GS]etVariable working at comptime + fixed a wired bug were mIntPtrType wasn't initialized

[Rune-Magic]

adding additional libpaths via build logic, would require changing the way linking commands are queued, so I'll leave it at that for now

[Rune-Magic]

Recap

• Compiler.BuildLogic
• Beef > General Options > Build Logic Object
• Console.Write[Line] in comptime
• Console.RunShellCommand

Example

class MyBuildLogic : BuildLogic
{
    public override void PreBuild()
    {
         String output = scope .(16);
         output.Append("archive.");
         if (Compiler.Options.Platform == .Windows)
             output.Append("lib");
         else
             output.Append('a');
             
         String buildDir = scope $"{Compiler.BuildDir}/{Compiler.ProjectName}";
         Console.RunShellCommand(scope $"clang -c -target {Compiler.Options.TargetTriple} -o {buildDir}/object.o file.cpp");
         Console.RunShellCommand(scope $"llvm-ar crs {buildDir}/{output} {buildDir}/object.o");
    }
}

[bfiete]

I do always appreciate a slam-dunk PRs: implementations of obviously missing funtionality, bug fixes, etc. This is definitely not that.

I appreciate that you have taken the initiative to fully design and develop a completely new feature, but there are some fundamental problems here:

1. There was no consensus reached ahead of time that this was actually a desirable set of features
2. These was no discussion about the potential downsides of these features
3. There was no determination of what the best way is to expose these kinds of features

This is a feature that requires thoughtful planning and consideration.

Unfortunately at this time I can neither accept this PR as-is, nor commit to the thoughtful planning and consideration to determine how and whether this kind of feature should be exposed.

[Rune-Magic]

okay, so I'll give you the full picture.

I was making a new binding generator (https://git.unicon-gmbh.de/BeefBindings/Cpp2Beef), and it basically done at this point. I then wanted to make a binding eco-system that automatically builds the c/c++ libraries. Most of the current beef bindings only expose win64 prebuild binaries, which is not really cross-platform and new version would have to put in manually.

What I wanted is a 1-click package manager git pull and everything just works out of the box without any tinkering. In order to do this I had it would have to build the c code from source, across all platforms and link it into the beef project. Now currently the only ways to execute something at build are build commands and comptime. Comptime doesn't really have the functionality to build stuff because:

• it can't run commands without either spawning a window in your face or you not getting any output
• it can't write stuff to the console, which means you can't even capture the output and write it
• it didn't have any knowledge about the build context (before Add more System.Compiler global variables #2407)

and most of this PR attempts to fix these issues. So the only option is prebuild commands. But there were so many issues I had with prebuild commands:

• prebuild commands are on a per-platform/config level, this means despite the commands being exactly the same for all builds, you still need to spam the commands 20 times for all major platforms and configurations.
• more importantly, my build logic (https://git.unicon-gmbh.de/BeefBindings/Cpp2Beef/src/branch/main/CxxBuilder) was written in beef, but build commands or commands. So I had to compile the build logic in my Setup logic. Then I had to save the location of the executeable to a file. Then I had to read that location ReadFile("$(ProjectDir Cpp2Beef.git)/CxxBuilder.txt", "CxxBuildPath") and then I had to execute it passing the build context (TargetTriple, Configuration). This is all a lot of effort, just to execute some beef code when building.
• writing commands into the tiny widgets is not really fun, while write beef code is much more pleasant.

So my first idea was something like zig has (a build.zig file), but this doesn't fit the current build system very well. But if you just execute some build logic at comptime that would fit and even be suppirior to what zig has because you have the full code base at your disposal, like in normal comptime. Now you could just make comptime more capable and:

class CompileC
{
    [Comptime, OnCompile(.TypeDone)]
    static void OnCompile()
    {
        if (!Compiler.IsBuilding) return;
        // ...
    }
}

while this might be a good compromise there is one thing it can't do, that the Compiler.BuildLogic class can: synconization. PreBuild is always executed as soon as possible and PostBuild is executed after linking. While this isn't really useful for compile c code, it can be for other use cases.

I am open to any revisions or stuctural changes, such as removing Compiler.BuildLogic and only keeping the build-time comptime improvements.

[bfiete]

Is it not feasible to use comptime to generate a shell/batch file that you can run in postbuild commands?

[Rune-Magic]

postbuild is well... post build so after linking, it needs to happen before linking.

[bfiete]

Prebuild then.

Currently the build process is:

1. Compile
2. Prebuild
3. Link
4. Postbuild

[Rune-Magic]

okay that works, but we can still get Console.Write[Line] and Environment.(S|G)etVeraible in comptime, even if I can't have Console.RunShellCommand?

[bfiete]

Yes, those are reasonable features to support.

[Rune-Magic]

new PR with build logic removed: #2417

[bfiete]

I went ahead and added support for Console.Write and the Environment.[G/S]etEnvironmentVariable fa01e14

[Rune-Magic]

why did you change the naming of Environment.GetVariable? that way it's easier to confuse it with the dictonary based API

[bfiete]

Because that's the right name for it.

[Rune-Magic]

#2417