A few packaging nits, coming from Nixpkgs/NixOS

[Ericson2314]

Hi, you can see how we currently package this in https://github.com/nixos/nixpkgs/blob/master/pkgs/development/libraries/wasilibc/default.nix.

There are no imminent problems (the situation is less fraught than I thought) but I few things I think could be improved.

Install dirs

We generally like to have "mutliple outputs" for our libraries. That means we install to something like /nix/store/random-foo/lib, /nix/store/random-bar/include, etc. notice the random-{foo,bar} are not the same.

We generally use the "GNU-style: install dirs" to achieve this. C.f.

• Autoconf: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Installation-Directory-Variables.html
• CMake: https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
• Meson: https://mesonbuild.com/Builtin-options.html#directories

You have

wasi-libc/Makefile

Line 8 in 079adff

SYSROOT ?= $(CURDIR)/sysroot

and

wasi-libc/Makefile

Lines 246 to 248 in 079adff

	SYSROOT_LIB := $(SYSROOT)/lib/$(MULTIARCH_TRIPLE)
	SYSROOT_INC = $(SYSROOT)/include
	SYSROOT_SHARE = $(SYSROOT)/share/$(MULTIARCH_TRIPLE)

for this. It would be nice to make the second ones ?= too, and relax the assumption that that they share a parent directory.

That list bit part means getting rid of other uses of SYSROOT (it can just be a way to default the defaults for those three, so e.g.:

Tool env vars

You use WASM_*, e.g. WASM_CC. The convention however is that CC, LD, etc. are the tools for the current package, for the current platform, one is installing too. Conversely, if one needed to build e.g. some temporary codegen tool (a common use case, but not on in wasi libc to my knowledge), one would use CC_FOR_BUILD, LD_FOR_BUILD etc.

This means the WASM_ prefix is not needed.

I would suggest just getting rid of them. The wrapper wasi-sdk already does recursive make:
https://github.com/WebAssembly/wasi-sdk/blob/20c5bcd791e22895ea1c9721c9bd88081e3ed1f6/Makefile#L92-L96

build/wasi-libc.BUILT: build/llvm.BUILT
	$(MAKE) -C $(ROOT_DIR)/src/wasi-libc \
		WASM_CC=$(BUILD_PREFIX)/bin/clang \
		...

This makes scoped variables easy, so you can just do

build/wasi-libc.BUILT: build/llvm.BUILT
	$(MAKE) -C $(ROOT_DIR)/src/wasi-libc \
		CC=$(BUILD_PREFIX)/bin/clang \
		...

instead, and not worry about clashes with any "global" CC.

[Ericson2314]

I would be more than happy to make a PR with the changes, but I figured I should open an issue first.

[sunfishcode]

Thanks for filing this! One question I have hear is, does Nix use this ability to have separate include and library directories to version them separately? Can users ask for an include directory from one version, and a library directory from another? This would imply a level of ABI stability that I don't know whether we're ready for.

[Ericson2314]

@sunfishcode Nix itself doesn't know what versions are on any deep level. Hashes are either

The culture around Nix happens to be "we can rebuild the world so easily, who cares about ABI stability!"

Can users ask for an include directory from one version, and a library directory from another?

Certainly Nix will not stop you from doing that (though certain conventions make it easier to prevent). If you do that....you get broken builds! No one would expect otherwise :).

[sbc100]

One difference between wasm-libc and other/normal software that you might want to package is that it is designed to be used only within the sysroot of a cross compiler. I assume you understand that and are creating some kind of packaged sysroot or cross toolchain? Given that, does it still make sense to be able to install/redirect headers and libraries using the normal packaging machinery that you have? For example, if I was packaging for linux I would not want wasm-libc to install in the same way the normal library would (i.e. honoring the the normal include and library paths).

[Ericson2314]

@sbc100 Yes we do! We are vary fastidious that our processes should work for all libraries alike.

My view is that the traditional distro special-casing was a sign that their methods didn't "scale" to begin with. Our "no global 'views'" / no ambient authority approach is very reminiscent of WASI's own; just as you could say file descriptors prove / is not necessary, we say our separate install paths for everything prove that /usr/lib is unnecessary.

If you don't have such global collections of things, you don't have to worry about what goes in them! :)

[sbc100]

Fair enough! Sounds like you have interesting alternative to the traditional notion of a sysroot (I can't say I understand how it all fits together but it sounds interesting).