Add a guix package description

[iamleeg]

The new file guix.scm lets people who checkout the library locally create a shell environment in guix with all necessary dependencies, and build their local version as a package. Commands:

1. to get a shell with the build dependencies: guix shell (or guix shell -CP to get a container environment without access to packages installed in your profile)
2. to build gnustep-base from this checkout: guix build -f guix.scm

This can form the basis for adding gnustep-base to the guix package list at gnu/packages/gnustep.scm. There's already a pull request to guix on codeberg to package gnustep libraries upstream; this PR makes local gnustep-base development on guix easier.

Some notes on the implementation:

1. gnustep-config invokes make with SHELL=/bin/sh, which doesn't exist in the build environment, so I work around that here. It would be better to patch tools-make so that it honours $SHELL; people who want to use /bin/sh can set the variable.
2. both tools-make and libs-base Makefiles use which to find commands, so I've added that as a dependency, but we could remove that if the Makefiles use the command shell built-in instead.
3. the filesystem layout that gnustep-make creates is unusable for building packages, because the build container writes to an output folder guix controls and doesn't have write access to the rest of the filesystem. Therefore guix.scm overwrites all the FS layout variables relative to the $out base folder for the package.

[rfm]

I have some questions/thoughts.

1. gnustep-make generally depends on a Bourne/posix compatible shell (bash compatible for the test framework) so I don't think using $SHELL is safe, but perhaps a test to see if /bin/sh exists, and fall back to $SHELL if it doesn't?
2. Given that 'command -v' is standard in posix shells, switching sounds like a good idea. Do you know of any downsides?
3. Is this issue because you are using a pre-installed gnustep-make which is outside your package environment, or did you just miss the --prefix= configure option. If the latter you could shorten the script a lot by just having gnustep-make set up the filesystem relative to your package root. That being said, you normally want to configure base so that the built in default paths match the layout you want the package installed in, or are located relative to the config file (and the config file relative to the base library). Without understanding installation policies it's impossible to know. However, you could always merge this change and modify later if it's not ideal.

[iamleeg]

1. that sounds like a good idea.
2. It should be OK. command -v echoes the path (for external commands; or the bare keyword for shell built-ins) and sets $? to 0 on success. It has no output and sets $? to 1 on failure. For the purpose to which gnustep-make puts it, that's sufficient (which also has the -a flag, which isn't relevant).
3. That's a good question. The patch that adds gnustep base (and gui and back) to the guix package repository has a different approach so I'll convert this to draft, and try to align this PR with the way they've done it so the "local development" environment is as close as possible to the "installed" package. I'll also talk with that person about whether we can use --prefix=$out; they've taken a similar approach to me and mapped the config. I think possibly we can't, because ./configure arguments run at the time you build gnustep-make, but you need to know the deploy destination at the time you build some dependent project (like -base in this case, or an app, or whatever).