On Tue, 5 Oct 2021 00:20:09 +0000 Paul Wise <pabs@debian.org> wrote:
> Please make sure the package is built solely from the source from
> scratch without any existing binaries using the upstream supported
> bootstrap process:
>
> https://github.com/ziglang/zig-bootstrap/
>
> Personally, I think merging zig-bootstrap into the zig source repo
> would make it easier for distros to use, but I hear upstream isn't
> interested in that.
Hi pabs,
Upstream is definitely interested in cooperating with Debian maintainers
to the benefit of our shared users :-)
I'm happy to discuss this suggestion. Here is some information to help
us sort this out:
* zig-bootstrap contains copy+pasted upstream sources from
- LLVM, LLD, Clang
- There is currently 1 tiny patch to LLD's build script to adjust
an include directory to depend on something inside zig-bootstrap rather
than to an external directory
- There are also some deleted files which is merely an attempt to
reduce tarball size; these could be restored to no harmful effect.
- Zig (no patches)
- zlib (no patches)
* Apart from this, the *only* utility that zig-bootstrap provides is a
short build script, which does the following process:
- Build LLVM, Clang, LLD, zlib, zig from source, for the host system
- Using freshly built native zig, use `zig cc`/`zig c++` to rebuild
LLVM, Clang, LLD, zlib, and zig again, from source, for the target system
This is useful for upstream to provide portable binaries of Zig,
however, I suspect that there is a better strategy which is more
compatible with Debian's guidelines. In fact, I have been keeping
Debian-friendliness in mind since the very beginning. I suspect you will
actually find the main build process more amenable to packaging.
In the main upstream repository (https://github.com/ziglang/zig/), it is
a standard cmake build that I believe is already Debian-compatible. I am
guessing you found the zig-bootstrap repository because you wanted to
avoid depending on a zig binary to build zig; what you may not realize
is that the main zig repository *does not utilize a zig binary* to be
built. In fact, the main cmake build process does the following things:
* Use the system C++ compiler to build zig0 executable using system
LLVM, LLD, Clang, zlib libraries
* Use the freshly built zig0 executable to build zig1.o
* Re-link some of the build artifacts, swapping in zig1.o, producing
the zig binary
I believe this is exactly what a Debian package wants, because you will
end up with a binary that
* Uses the system LLVM, LLD, Clang, zlib libraries
* Was built with the system C/C++ compiler and linker
I suggest to try out the main, standard way of building Zig and let me
know if you run into any trouble. I suspect the main issues will be:
* deps/SoftFloat-3e is a vendored library. I would be happy to improve
the cmake build script to enable an option to prefer the system
SoftFloat library instead.
* lib/libcxx, lib/libcxxabi, lib/libunwind, lib/tsan and lib/include
are copy+pasted (MIT-compatibly licensed) from other upstreams, and
there are quite a few patches and preprocessing which is part of the zig
development process. I am hoping that Debian can grant zig an exception
for these files and not require them to be built by a debian package.
These files are part of the "magic" that makes zig attractive in the
first place, and although these files may look like they should be
provided by other debian packages, I think if you examine closely you
will find that they are really derived works that are part of the zig
project.
I hope this helps. I am happy to work together on this :-)
Warm regards,
Andrew