12 ms·

I'm working on packaging Fil-C for Nix, as well as integrating Fil-C as a toolchain in Nix so you can build any Nix package with Fil-C. https://github.com/mbro

by mbrock 1y ago

I'm working on packaging Fil-C for Nix, as well as integrating Fil-C as a toolchain in Nix so you can build any Nix package with Fil-C. https://github.com/mbrock/filnix https://github.com/mbrock/filnix It's working. It builds tmux, nethack, coreutils, Perl, Tcl, Lua, SQLite, and a bunch of other stuff. Binary cache on https://filc.cachix.org https://filc.cachix.org so you don't have to wait 40 minutes for the Clang fork to build. If you have Nix with flakes on a 64-bit Linux computer, you can run nix run github:mbrock/filnix#nethack right now!

kragen 1y ago
That's very exciting! Thank you!
yjftsjthsd-h 1y ago
That is super cool, and I will probably start running it on at least a test box shortly. How does python work? Of course I can just add filc.python to my system, but if I `python3 -m pip install whatever` will it just rebuild any C modules with the fil-c compiler?
- mbrock 1y ago
  Right now Python simply does not work at all. I was trying last night just to get the compiler to build, but ran into some Fil-C panics at the last moment when it tries to "freeze" some modules? But it should work. My idea is to move towards defining Fil-C as a "platform", meaning it would have its own ABI value, so it would look like a target called "x86_64-unknown-linux-filc", and then the magic of Nixpkgs is that it can instantiate a full realm called "pkgsCross.filc" which automatically has every package, whose packages are built on your ordinary non-FilC platform as a cross compilation. When that works—I hope it works, I probably need help to get it working—you should be able to use all the Nixpkgs packaging helpers like pkgs.mkShell { packages = [ (pkgsCross.filc.python3.withPackages (pypkgs: with pypkgs; [ pandas requests ])) ]; } This is already how Nixpkgs can have a pkgsCross.musl that builds everything with Musl as a cross compilation. So it seems reasonable and possible. It should be of wide interest for Nix users, since it would suddenly allow memory safety for whole swaths of the C/C++ packages, it would let NixOS use memory safe builds for core services like OpenSSHd, and so on... I should probably try to gather some interest among people who are truly familiar with Nixpkgs cross compilation...
  - Cloudef 1y ago
    Yes filc as abi makes most sense. Do note that while fil-c seems to have pretty good source compatibility some stuff still require patches (like python!)
    - yjftsjthsd-h 1y ago
      I don't know how it's going on the nixpkgs side, but my impression from Alpine is that it's pretty normal to carry some patches for any ABI/platform that isn't GNU.
      - mbrock 1y ago
        Yep, you can look around in Nixpkgs and see a bunch of conditionally applied patches based on target platform. My Fil-C flake already includes like 50 different patches extracted from the upstream port catalogue!
Cloudef 1y ago
Yeah, I was thinking nix will be probably one of the first things that can easily adapt Fil-C as it already packages in a way that allows different packages to be completely independent of each other, thus Fil-C's ABI compatibility does not matter. I assume other targets will be mostly enterprise distros where the perf hit and source compatibility issues are less of a concern, and memory safety is absolutely critical. Fil-C compiled flatpaks might be a interesting target as well for normal desktop users. (e.g. running a browser) I wonder if GPU graphics are possible in Fil-C land? Perhaps only if whole mesa stack is compiled using Fil-C as well, limiting GPU use to open drivers?

by mbrock 1y ago

kragen 1y ago

That's very exciting! Thank you!

yjftsjthsd-h 1y ago

That is super cool, and I will probably start running it on at least a test box shortly. How does python work? Of course I can just add filc.python to my system, but if I `python3 -m pip install whatever` will it just rebuild any C modules with the fil-c compiler?

mbrock 1y ago
Right now Python simply does not work at all. I was trying last night just to get the compiler to build, but ran into some Fil-C panics at the last moment when it tries to "freeze" some modules? But it should work. My idea is to move towards defining Fil-C as a "platform", meaning it would have its own ABI value, so it would look like a target called "x86_64-unknown-linux-filc", and then the magic of Nixpkgs is that it can instantiate a full realm called "pkgsCross.filc" which automatically has every package, whose packages are built on your ordinary non-FilC platform as a cross compilation. When that works—I hope it works, I probably need help to get it working—you should be able to use all the Nixpkgs packaging helpers like pkgs.mkShell { packages = [ (pkgsCross.filc.python3.withPackages (pypkgs: with pypkgs; [ pandas requests ])) ]; } This is already how Nixpkgs can have a pkgsCross.musl that builds everything with Musl as a cross compilation. So it seems reasonable and possible. It should be of wide interest for Nix users, since it would suddenly allow memory safety for whole swaths of the C/C++ packages, it would let NixOS use memory safe builds for core services like OpenSSHd, and so on... I should probably try to gather some interest among people who are truly familiar with Nixpkgs cross compilation...
- Cloudef 1y ago
  Yes filc as abi makes most sense. Do note that while fil-c seems to have pretty good source compatibility some stuff still require patches (like python!)
  - yjftsjthsd-h 1y ago
    I don't know how it's going on the nixpkgs side, but my impression from Alpine is that it's pretty normal to carry some patches for any ABI/platform that isn't GNU.
    - mbrock 1y ago
      Yep, you can look around in Nixpkgs and see a bunch of conditionally applied patches based on target platform. My Fil-C flake already includes like 50 different patches extracted from the upstream port catalogue!

Cloudef 1y ago

Yeah, I was thinking nix will be probably one of the first things that can easily adapt Fil-C as it already packages in a way that allows different packages to be completely independent of each other, thus Fil-C's ABI compatibility does not matter. I assume other targets will be mostly enterprise distros where the perf hit and source compatibility issues are less of a concern, and memory safety is absolutely critical. Fil-C compiled flatpaks might be a interesting target as well for normal desktop users. (e.g. running a browser) I wonder if GPU graphics are possible in Fil-C land? Perhaps only if whole mesa stack is compiled using Fil-C as well, limiting GPU use to open drivers?