Meta: Get building on NixOS

[sophiajt]

Managed to get this building on NixOS and figured I'd turn it into a PR so it didn't get lost. The gist is largely to not use /bin/bash or /bin/mkdir, since those aren't available on NixOS and instead use env to find where they are.

The rest of this is setting up the build dependencies so that both the bootstrap and Serenity can build successfully.

[bugaevc]

Does it actually work to specify multiple arguments in shebangs?

[asynts]

I remember running into this when changing Serenity's env. Some env implementations allow that by default and others require a -S flag or something like that.

[bugaevc]

I see, so the kernel passes everything following the initial binary name as a single argument (in this case, /usr/bin/env "bash ../.port_include.sh"), and the env implementation can then optionally support splitting this as a shell would otherwise do it.

[sophiajt]

Sorry, I'm not quite following - is there a change you'd like me to do here?

[bugaevc]

You might need to add -S as @asynts says

[sophiajt]

Updated

[emanuele6]

I think using -S breaks support for OpenBSD: https://man.openbsd.org/env.1

[asynts]

Portability in a nutshell...

[sophiajt]

So no -S? 😅

[emanuele6]

@jonathandturner: I don't think it would work without it.

EDIT:

[bugaevc]

Not to sound negative — being able to build Serenity on Guix would be great 😀 —

but the idea that /bin/env is a well-known path but /bin/sh is not one (and so all the sh invocations have to be proxied through env) sounds backwards to me. I'd expect any system that places its shell in an unusual location to provide the necessary symlinks or some other mechanism to make existing software work, rather than requiring everything to proxy binary invocations through env.

But I realize that ship has sailed, and the design of Nix/Guix is not gonna change because of my preferences.

[ADKaster]

Whoops, looks like an unresolved merge conflict snuck in. I also noticed there's a merge commit in your commit list -- we like to follow a rebase + squash workflow so that commits can be directly placed in master from each PR. https://github.com/SerenityOS/serenity/blob/master/CONTRIBUTING.md#code-submission-policy

[sophiajt]

Good catch!

[emanuele6]

Can't we somehow use cmake to make directories instead of using /usr/bin/env -S mkdir -p ...?

[emanuele6]

Suggested change

	COMMAND /usr/bin/env -S mkdir -p CSS
	COMMAND ${CMAKE_COMMAND} -E make_directory CSS

https://stackoverflow.com/a/3702233

[emanuele6]

Also, this didn't need -S since it is not a shebang.

[awesomekling]

All right, let's get this merged since it seems fine, although I have a strong feeling that NixOS build support will bitrot unless somebody uses it regularly.

[linusg]

Why do some shebangs say #!/usr/bin/env bash and some say #!/usr/bin/env -S bash now?

[emanuele6]

@linusg: because of how arguments are passed to programs with shebangs:

With #!/usr/bin/env bash, env will get bash and the filename as arguments which is fine.
With #!/usr/bin/env bash ../.port_include.sh, env will get bash ../.port_include.sh and the filename as arguments which is not fine because we don't want to run the file with a program called bash ../.port_include.sh which probably doesn't exist, we want to run it with bash.
To solve this issue, some implementations of env have added an -S (--split-string) "option" which tells env that if it gets an argument that looks like -S something somethingelse it should treat it as two (or more, splitting spaces) seperate arguments: something and somethingelse.
Sadly, since env wasn't meant to be used in shebangs originally, this option is not defined in POSIX.