Provide build.zig for building libgc?

[plajjan]

I've been using zig in some projects and I think it's really nice. One of the things it offers is a build system, replacing Make, CMake and similar. In fact, one of Zigs goals is to offer a better build system not just for Zig projects but for C projects and they aspire to do a better job than all the other systems out there. I think they do or at the very least that they are on a trajectory to.

https://ziglang.org/learn/overview/#zig-build-system

I've recently started switching over the Acton project to use Zigs build system in various places (building Acton itself but also later, since Acton is a language that generates C, it uses zigs build system to produce the final .o, .a and executables). As part of this, I've looked at using zig to build libgc. One of the things it unlocks is easily being able to cross-compile:

kll@Boxy:~/terastream/acton/dep/libgc$ uname -s -m
Linux x86_64
kll@Boxy:~/terastream/acton/dep/libgc$ zig build --prefix . -Dtarget=aarch64-macos-none
kll@Boxy:~/terastream/acton/dep/libgc$ ar x lib/libgc.a 
kll@Boxy:~/terastream/acton/dep/libgc$ file alloc.o
alloc.o: Mach-O 64-bit arm64 object, flags:<|SUBSECTIONS_VIA_SYMBOLS>

My hacked up build.zig is catering towards the needs of Acton. I wonder, would there be an interest in having and maintaining a build.zig in the bdwgc repo itself? I could probably make an initial proposal at least :)

[ivmai]

At this moment, I don't see the benefits over cmake, and it looks to be not among popular build systems.
I'd prefer to wait for now. To remind, bdwgc could be built in 4 ways - by cmake, by configure, by gnu make (direct) and w/o any build system.
Let's keep this issue open.

[plajjan]

I understand, and probably even agree :) Maintaining yet another build thingy obviously takes time and effort!

[plajjan]

For anyone surfing by and having an interest in this, I maintain a fork of bdwgc with a build.zig. It is primarily catering to the needs of the Acton language, so I haven't gone out of my way to support all features or all platforms, rather keeping it simple. However, if anyone is lacking anything, I'm happy to add and so perhaps over time it can mature to be rather complete.

[ivmai]

On behalf of @plajjan (copied from #588):
FWIW, https://github.com/actonlang/bdwgc/tree/zig-build is the branch I'm using to build that includes a build.zig file if anyone wants to try this out :)

[plajjan]

Haha, yes, I meant to include the link. Thanks Ivan :)

[ivmai]

Okay, I think it would be OK to add some minimalist version of the build.zig.
But let's keep it synchronized with cmake or configure/automake, even having smaller amount of supported options and targets.

Could you please modify the build.zig and zig-build.yml like this:

• support Linux/x86_64 target (I think it would be better to exclude specific code e.g. for wasi and musl from the 1st commit to simplify review)
• support multi-threaded shared build (i.e. what configure && make and cmake without additional arguments do)
• optionally support enable_threads=false and enable_shared=false options (but not in the 1st commit)
• use some stable zig version in zig-build.yml (i.e. not dev.1814+5c0d58b71) if possible
• install same set of headers as cmake does
• use same set of -D options as cmake does (by default on Linux/x64)
• use same set of source files (extra/gc.c + pthread_start.c in case of shared build)
• add bdwgc-style license header to build.zig (e.g. see tests/tests.am for the minimum license header)
• document build process at least in README.md (advanced usage could be documented later in docs/README.zig)

[plajjan]

Okay, sure! I can modify the current build.zig I have. I would like to keep the current functionality though, like building static lib and musl support, since that's what I use in Acton and I'd prefer not to diverge. Hope that's ok.

Zig's build system have undergone massive changes. A lot of it landed in zig 0.11 but there were some smaller changes that are in 0.12. Lately, the rate of changes has dropped drastically as it approaches a more stable design, so 0.12 will probably be a good release once it's out. Until then we have the choice of either going with a nightly release or go back to 0.11. I would hate going with 0.11 since it means a different and older API for the build system. I think we should try and target the "final version" which a 0.12 nightly is closer to (maybe we're at the final version now!). Zig is young and immature, with a large portion of users being on some nightly version, so I think we need to also take this into when making our choice! We could of course also wait until zig 0.12 is out...

[plajjan]

• align options with cmake
  • enable_threads
  • enable_disclaim
  • enable_cplusplus
  • enable_parallel_mark
  • enable_large_config
  • enable_redirect_malloc
• use same set of source files (I'm missing extra/gc.c right now (how come the GC still works? 😋))
• support shared build
• add license header from tests/tests.am
• add section in README.md on how to use
• install same set of headers
  • build.zig includes whole include/gc directory
  • cmake does not install gc/gc_allocator.h & gc/gc_cpp.h (they are for c++)

[ivmai]

Please do not align with Makefile.direct.
Align with 1. Cmake, 2nd priority is configure (aligning with just cmake would be OK)

[plajjan]

@ivmai ok, will align on Cmake! I've actually already seen discrepancies between Makefile.direct and Cmake and have chosen to align on cmake :)

Can you shed some light on the following code:

...
  # Thread support detection.
  if (CMAKE_USE_PTHREADS_INIT)
    set(SRC ${SRC} gc_dlopen.c pthread_start.c pthread_support.c)
    if (CYGWIN OR WIN32)
      set(SRC ${SRC} win32_threads.c)
    else()
      if (APPLE)
        set(SRC ${SRC} darwin_stop_world.c)
      else()
        set(SRC ${SRC} pthread_stop_world.c)
      endif()
    endif()
...

I wonder about this line, shouldn't it be conditioned on being on a posix system / not on windows?

    set(SRC ${SRC} gc_dlopen.c pthread_start.c pthread_support.c)

[ivmai]

I wonder about this line, shouldn't it be conditioned on being on a posix system / not on windows?
set(SRC ${SRC} gc_dlopen.c pthread_start.c pthread_support.c)

No, e.g. MSVC + libpthreads-w32 needs at least 2 of these files.

[ivmai]

Also, update .gitignore if needed (so that zig output and intermediate artifacts not seen by git status).

[ivmai]

The PR is #598

[ivmai]

Some resources about zig (tip for me):

• https://zig.news/xq/zig-build-explained-part-2-1850
• https://ziglearn.org/chapter-1/
• https://ziglang.org/learn/build-system/

[ivmai]

Solved in PR #598

[ivmai]

@plajjan I'd like to thank you for your contribution! Zig build looks cool:)

[plajjan]

@ivmai you're welcome, glad to see stuff merged.. and yes, I think it is quite cool, it's quite enjoyable to work with :)