Zig: ability to run `make` as a meaningfully separate target than `make install`

[jonathonf]

Manjaro/Arch Linux, trying with Zig commit https://github.com/ziglang/zig/commit/f429f4dcabec2324b76b900f5785204897ea7685, using PKGBUILD here: https://aur.archlinux.org/packages/zig-git (edited to exclude force_dynamic_llvm.patch now https://github.com/ziglang/zig/pull/2858 is merged).

Relevant build section:

build() {
    cd "$srcdir/$provides"
    mkdir -p build
    cd build
    cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
    make
}

Might be related to https://github.com/ziglang/zig/issues/2340

---

This command:

/tmp/zig/build/zig0 /tmp/zig /tmp/zig/zig-cache --override-std-dir std --override-lib-dir /tmp/zig libuserland install -Doutput-dir=/tmp/zig/build -Dlib-files-only --prefix /usr

appears to be attempting to write directly into /usr; setting CMAKE_INSTALL_PREFIX to a user-writeable location will allow the command to complete successfully.

This is not ideal for distro packaging. ;)

---

Full output:

```lines=10
[ 99%] Built target zig0
Scanning dependencies of target zig_build_libuserland
error: AccessDenied
/tmp/zig/std/os.zig:1007:19: 0x26d6fa in std.os.mkdirC (build)
EEXIST => return error.PathAlreadyExists,
^
/tmp/zig/std/os.zig:992:9: 0x26d604 in std.os.mkdir (build)
return mkdirC(&dir_path_c, mode);
^
/tmp/zig/std/fs.zig:273:5: 0x26d4dd in std.fs.makeDir (build)
return os.mkdir(dir_path, default_new_dir_mode);
^
/tmp/zig/std/os.zig:537:23: 0x255caf in std.os.openC (build)
ENOENT => return error.FileNotFound,
^
/tmp/zig/std/fs/file.zig:45:20: 0x24025a in std.fs.file.File.openReadC (build)
const fd = try os.openC(path, flags, 0);
^
/tmp/zig/std/fs/file.zig:35:9: 0x253de0 in std.fs.file.File.openRead (build)
return openReadC(&path_c);
^
/tmp/zig/std/os.zig:1012:19: 0x26d759 in std.os.mkdirC (build)
ENOENT => return error.FileNotFound,
^
/tmp/zig/std/os.zig:992:9: 0x26d604 in std.os.mkdir (build)
return mkdirC(&dir_path_c, mode);
^
/tmp/zig/std/fs.zig:273:5: 0x26d4dd in std.fs.makeDir (build)
return os.mkdir(dir_path, default_new_dir_mode);
^
/tmp/zig/std/os.zig:1004:19: 0x26d6c1 in std.os.mkdirC (build)
EACCES => return error.AccessDenied,
^
/tmp/zig/std/os.zig:992:9: 0x26d604 in std.os.mkdir (build)
return mkdirC(&dir_path_c, mode);
^
/tmp/zig/std/fs.zig:273:5: 0x26d4dd in std.fs.makeDir (build)
return os.mkdir(dir_path, default_new_dir_mode);
^
/tmp/zig/std/fs.zig:312:21: 0x26d120 in std.fs.makePath (build)
else => return err,
^
/tmp/zig/std/build.zig:2188:31: 0x29ac7b in std.build.InstallDirStep.make (build)
.Directory => try fs.makePath(self.builder.allocator, dest_path),
^
/tmp/zig/std/build.zig:2292:9: 0x26e459 in std.build.Step.make (build)
try self.makeFn(self);
^
/tmp/zig/std/build.zig:334:9: 0x26ceaa in std.build.Builder.makeOneStep (build)
try s.make();
^
/tmp/zig/std/build.zig:328:17: 0x26ce5c in std.build.Builder.makeOneStep (build)
return err;
^
/tmp/zig/std/build.zig:289:13: 0x262627 in std.build.Builder.make (build)
try self.makeOneStep(s);
^
/tmp/zig/std/special/build_runner.zig:137:21: 0x25fc4c in main (build)
else => return err,
^

Build failed. The following command failed:
/tmp/zig/zig-cache/o/QOfS5iNb5Lq3IZnGM0HEiOUAl_cNHdPr_eeLIzxoiPqBkQX-wU731ehfXBHpmne6/build /tmp/zig/build/zig0 /tmp/zig /tmp/zig/zig-cache --override-std-dir std --override-lib-dir /tmp/zig libuserland install -Doutput-dir=/tmp/zig/build -Dlib-files-only --prefix /usr
```

[andrewrk]

You're passing -DCMAKE_INSTALL_PREFIX=/usr which tells it to install to /usr. What did you expect it to do instead?

[jonathonf]

I think it's normally used to set the prefix to be picked up by make install later on. The build process probably shouldn't be installing files?

I'm looking at https://github.com/ziglang/zig/commit/3f4abe97bdbe666dbb3532c14a97e414aae4caca which looks to have added installation into zig build

[andrewrk]

is there any reason you can't run make install directly? why do you need to do make separately?

[jonathonf]

It's part of the Arch packaging standards, https://wiki.archlinux.org/index.php/Creating_packages#build()

The build() and package() steps have different purposes and environment variables available to them. While it's possible to skip the build() step and just do everything in package() I know it would be strongly criticised by the Arch TUs.

In any event, the build process still fails even if I clump everything into one place:

package() {
    mkdir -p "$srcdir/$provides"/build
    cd "$srcdir/$provides"/build

    cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr

    install -Dm644 "$srcdir/$provides/LICENSE" "$pkgdir/usr/share/licenses/$provides/LICENSE"
    make DESTDIR="$pkgdir" install
}

It looks like it's still trying to install directly into /usr and ignoring the $DESTDIR variable (same error output as above).

[andrewrk]

It's part of the Arch packaging standards, https://wiki.archlinux.org/index.php/Creating_packages#build()

OK, this is good enough reason for me to make upstream changes. However I will put it behind a cmake flag because having make do this installation step by default is faster for upstream development and avoids the issue of new users forgetting to make install.

Does that sound reasonable?

Regarding DESTDIR it sounds like the desired behavior is that this environment variable will override CMAKE_INSTALL_PREFIX. Is that correct? Why pass -DCMAKE_INSTALL_PREFIX at all, if you plan to override this value later with DESTDIR?

[jonathonf]

CMAKE_INSTALL_PREFIX (this would generally be just PREFIX for e.g. autotools) sets the end-result target install location where it's necessary for compiled/produced files, e.g. rpaths or in wrapper scripts or whatever.

DESTDIR is overriding where make install will put the files.

The two variables serve subtly different purposes but both are necessary for building then packaging software for distribution.

avoids the issue of new users forgetting to make install

As an aside, I'm not convinced that's a good reason; make; make install is a pretty standard process.

[andrewrk]

I pushed 77c2ac3fcd27b114b0068d3b64b3d884aa71e4ef to master which adds support for DESTDIR.

I'll leave this issue open to track separating make and make install.

[jonathonf]

The package builds again! 🥳

[andrewrk]

I believe this is now resolved with @mikdusan's new cmake patch.