feat(libint): add package

[jaudiger]

Add a new package libint: high-performance library for computing Gaussian integrals in quantum mechanics

Running brioche-run
{
  "name": "libint",
  "version": "2.11.1",
  "repository": "https://github.com/evaleev/libint"
}

⏵ Task `Run package live-update` finished successfully

Build finished, completed (no new jobs) in 1.25s
Result: a46f967599de18756a9901472b4f31874e2ea798c419c14179ad03e8fb0a4155

⏵ Task `Run package test` finished successfully

[jaudiger]

I'm not quite satisfied with this PR, yet @kylewlacy. I opened it for discussion.

[jaudiger]

libint is using a lot of absolute path to invoke rm. The issue is: rm int present at the location /bin/rm, so I had to update all the path to not be absolute. But is there another way to do it when mounting the environment in which the recipe is built ? I'm not quite sure, but from my months of testing, I think I already encountered this issue previously (having a log stating that rm command was not found), but this time, without the patch, the library cannot be built correctly.

[jaudiger]

Of course, this also applies to other basic command that are part of the std native toolchain.

[kylewlacy]

I know of 3 packages off the top of my head that have had issues with the Brioche sandbox root lacking some common things: CMake which we resolved with patches, plus Zig and MySQL (both I started on but paused since it seemed like potentially more work than CMake)

Actually, I added bubblewrap some time ago knowing that we'd probably want to do some builds within, say, an Ubuntu rootfs 🙂

I haven't looked at libint too closely, this might be a first good candidate to try out some of that work maybe? As a first pass, I think we could write a helper utility that would end up looking like this?

import { withinRootfs } from "bubblewrap";

const ubuntuRootfs = Brioche.download("...");

withinRootfs(ubuntuRootfs).runBash`
  # shell script here (runs within bubblewrap sandbox within rootfs)
`

(longer-term, I think we might want to move more towards middleware for std.process maybe? that's a pretty fuzzy idea right now though)

If we had that, do you think that could help clean up the libint build?

[jaudiger]

longer-term, I think we might want to move more towards middleware for std.process maybe? that's a pretty fuzzy idea right now though

I think so, for longer term, I think we should reduce the burden on the recipes side. Those kind of work should be abstract in the std package.

If we had that, do you think that could help clean up the libint build?

For sure, it would help to clean up the recipe of libint. Since it's kinda weird right now to tweak the path of rm command.

I haven't looked at libint too closely, this might be a first good candidate to try out some of that work maybe? As a first pass, I think we could write a helper utility that would end up looking like this?

Indeed, it would be a good first candidate, I put this PR on draft to give us time to work on that.

[jaudiger]

I know of 3 packages off the top of my head that have had issues with the Brioche sandbox root lacking some common things: CMake which we resolved with patches, plus Zig and MySQL (both I started on but paused since it seemed like potentially more work than CMake)

Also same thing, I have a few packages locally that do not yet build due to issues. And one of them is ruby, it will require more work