Add build.zig and integrate with CI

[Avokadoen]

This commit adds zig build and mimics cmake where it makes sense. There are some differences. As an example zig build does not support installing the build onto the system. It also will always include the c headers as the main purpose of this is to allow c/c++/zig projects to use the zig package manager to interface with enkiTS.

This PR resolves #142

[Avokadoen]

@dougbinks I'll fix some of the rough edges as soon as I have time (hopefully tomorrow). Although the PR is still a draft (see TODOs in build.zig and task_priorities is not properly used yet), please take a look when you have time :D

[Avokadoen]

@dougbinks I think I may have found a enkiTS bug?
Running latest version with priorities=2 seems to cause some OOB issue?

~/projects/enkiTS (zig-build)
$ zig build -Dbuild_examples=true -Dtask_priorities=2 run-Priorities
thread 39604 panic: index 2 out of bounds for type 'TaskPipe *[2]'
C:\Users\Aksel\projects\enkiTS\src\TaskScheduler.cpp:826:0: 0x7ff7efdf949e in enki::TaskScheduler::SplitAndAddTask (enki_ts.lib)
        if( !m_pPipesPerThread[ subTask_.pTask->m_Priority ][ threadNum_ ].WriterTryWriteFront( taskToAdd ) )

C:\Users\Aksel\projects\enkiTS\src\TaskScheduler.cpp:881:0: 0x7ff7efdf38a5 in enki::TaskScheduler::AddTaskSetToPipeInt (enki_ts.lib)
    SplitAndAddTask( threadNum_, subTask, rangeToSplit );

C:\Users\Aksel\projects\enkiTS\src\TaskScheduler.cpp:896:0: 0x7ff7efdfb904 in enki::TaskScheduler::AddTaskSetToPipe (enki_ts.lib)
    AddTaskSetToPipeInt( pTaskSet_, gtl_threadNum );

C:\Users\Aksel\projects\enkiTS\example\Priorities.cpp:65:0: 0x7ff7efdf1147 in main (Priorities.obj)
    g_TS.AddTaskSetToPipe( &lowPriorityTask );

C:\Program Files\Zig\lib\libc\mingw\crt\crtexe.c:259:0: 0x7ff7efdf2eab in __tmainCRTStartup (crt2.obj)
    mainret = _tmain (argc, argv, envp);

C:\Program Files\Zig\lib\libc\mingw\crt\crtexe.c:179:0: 0x7ff7efdf2f0b in mainCRTStartup (crt2.obj)
  ret = __tmainCRTStartup ();

???:?:?: 0x7ffd98ede8d6 in ??? (KERNEL32.DLL)
???:?:?: 0x7ffd99d48d9b in ??? (ntdll.dll)
run-Priorities
└─ run exe Priorities failure
error: the following command exited with error code 3:
"C:\\Users\\Aksel\\projects\\enkiTS\\zig-out\\bin\\Priorities.exe"

Build Summary: 46/48 steps succeeded; 1 failed
run-Priorities transitive failure
└─ run exe Priorities failure

error: the following build command failed with exit code 1:
.zig-cache\o\b57cc2c1be65c9ce9a84b6fb8edbfe5f\build.exe C:\Program Files\Zig\zig.exe C:\Program Files\Zig\lib C:\Users\Aksel\projects\enkiTS .zig-cache C:\Users\Aksel\AppData\Local\zig --seed 0xf75168be -Zf4d0df278e2159d5 -Dbuild_examples=true -Dtask_priorities=2 run-Priorities

[Avokadoen]

Using i.e -Dtask_priorities=3 works fine

[dougbinks]

@dougbinks I think I may have found a enkiTS bug?
Running latest version with priorities=2 seems to cause some OOB issue?

I can't replicate this in C++.

If I set ENKITS_TASK_PRIORITIES_NUM=1 then I get a build error:

enkiTS\example\Priorities.cpp(32,33): error C2039: 'TASK_PRIORITY_LOW': is not a member of 'enki'

Which is as expected. I could add range checks to the priorities but I'd rather setting a wrong priority failed at compile or run time than silently do the wrong thing, which could end up in a random deadlock.

[dougbinks]

I think there's something wrong with the setting of ENKITS_TASK_PRIORITIES_NUM in your build files or Zig is not setting the enum values as I'd expect.

[Avokadoen]

Fixed. When compiling the examples, ENKITS_TASK_PRIORITIES_NUM was not properly defined (only the lib had the current NUM).

[dougbinks]

Thanks for solving that.

I have a couple of questions:

1. Can the version in build.zig.zon be automatically pulled from the github release tag? Not a big issue if not but it looks like otherwise I will need to maintain this.
2. The fingerprint field in build.zig.zon does not seem to be well thought out by the Zig team, or I have not comprehended their documentation which reads:

When forking a Zig project, this fingerprint should be regenerated if the upstream project is still maintained. Otherwise, the fork is hostile, attempting to take control over the original project's identity. The fingerprint can be regenerated by deleting the field and running zig build.

Forks are a natural part of the git ecosystem, and I can't see everyone who forks enkiTS generating a new fingerprint (most won't even be aware of it). I am unsure how this is supposed to work unless the fingerprint also combines with the URL.

I note that the documentation also states that Version selection and related tooling that takes advantage of fingerprint is not implemented yet. so perhaps this is not something I need to worry about.

[Avokadoen]

Can the version in build.zig.zon be automatically pulled from the github release tag?

I could write an option in the build that will do that. Then you (or I in this PR) can do the plumbing in either the CI yam, or use a simple script to get the current git tag, and then do something like zig build --version=<version>.

You can access the zon file from the build script with something like:

const zon = @import("build.zig.zon");

const options = b.addOptions();  
options.addOption([]const u8, "version", zon.version);  

based on this

The fingerprint field in build.zig.zon does not seem to be well thought out

I would not be surprised if it isnt yet. All of this is very much WIP as well given that zig is still in a unreleased stage. Currently nothing will break if you fork enkiTS and then zig fetch that fork instead.

[dougbinks]

I think for the moment it might be easier just to update the version every time, as it's fairly infrequent. If the fingerprint system changes then hopefully you or some other Zig user of enkiTS can help me change it if needed!

Are there any other issues you need to resolve or shall I merge this?

[Avokadoen]

Yeah, I'll try to keep it up to date. Otherwise feel free to ping me and I may be available to help! The patch should be working and ready to be merged 😁

[dougbinks]

Merged, many thanks!