4 ms·

Re a new version of inkscape: Ninja does not force fully-correct builds, so it's on the author of the build.ninja file to either model this or not. (This is pa

by evmar 6y ago

Re a new version of inkscape: Ninja does not force fully-correct builds, so it's on the author of the build.ninja file to either model this or not. (This is part of Ninja's objective of not mandating policy.) To get this fully correct, note that you would need to model all inputs that Inkscape might read, which includes not only binaries but also configuration files or dynamically-loaded plugins. Some systems (I think tup?) track this by tracing executed binaries to see which file system operations they do. Even with tracing it can be really subtle: for example if a C file has an #include "foo.h", creating a new file named foo.h earlier in the include search path is a meaningful change, which means a file-access-tracing build system also needs to track file-not-found results from previous executions. (For C programs, also note that getting header dependencies correct includes similarly tracking all the headers in /usr/include that your program transitively includes. See the -MD vs -MMD flags to gcc.)

patrec 6y ago
> Even with tracing it can be really subtle The correct way of doing this is not tracing but a hermetic build. If you do a sandboxed build with nix, you will get a specific version of inkscape with a specific hash, which includes will include any inkscape extensions you include. And since the build will only be able to read files in the sandbox, none of the problems you list above can happen -- you can't pull random stuff from the network either. https://nixos.wiki/wiki/Nix#Sandboxing https://nixos.wiki/wiki/Nix#Sandboxing
- evmar 6y ago
  What you wrote is true, but it also seems to me unlikely that the OP is going to set up a sandboxed hermetic build to process a handful of pngs for her zine. I was instead explaining why Ninja doesn't attempt clever tricks to try to better approximate correctness.
  - patrec 6y ago
    > What you wrote is true, but it also seems to me unlikely that the OP is going to set up a sandboxed hermetic build to process a handful of pngs for her zine. But it's trivial! Assuming you fix the OP's Makefile (so much for Makefile syntax usability): # put into Makefile THINGS_TO_CONVERT := $(wildcard *.svg) all: $(patsubst %.pdf,%.svg,$(THINGS_TO_CONVERT)) inkscape $< --export-text-to-path --export-pdf=$@ # put into default.nix with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/7ad5e816faba3f808e2a8815b14d0f023a4e2160.tar.gz") {}; stdenv.mkDerivation { name = "zine-images"; src = ./.; buildInputs = [ inkscape ]; installPhase = "mkdir $out && cp *.pdf $out"; } Now make sure you have sandbox=true in /etc/nix.conf, run `nix build` in the directory, and boom done: hermetic build of zine images. Good thing too, I got a warning about --export-pdf being deprecated when I ran this. Note that running make or the dependency on make is not explicitly specified, mkDerivation has some basic smarts to figure out from the presence of a Makefile that it should run make. (Hardcoding the version of nixpkgs directly into the default.nix just for demo purposes, better to use niv or similar to manage a json file with versions for you).
    - patrec 6y ago
      Of course we could also get rid of the Makefile and simply add a buildPhase like this: buildPhase = "find -maxdepth 1 -name '*.svg' -print0 | xargs --null -I'{}' -n1 inkscape '{}' --export-text-to-path --export-pdf={}.pdf"; This should also handle filenames with spaces etc. correctly (although I have not tested it).

by evmar 6y ago

patrec 6y ago

> Even with tracing it can be really subtle The correct way of doing this is not tracing but a hermetic build. If you do a sandboxed build with nix, you will get a specific version of inkscape with a specific hash, which includes will include any inkscape extensions you include. And since the build will only be able to read files in the sandbox, none of the problems you list above can happen -- you can't pull random stuff from the network either. https://nixos.wiki/wiki/Nix#Sandboxing https://nixos.wiki/wiki/Nix#Sandboxing

evmar 6y ago
What you wrote is true, but it also seems to me unlikely that the OP is going to set up a sandboxed hermetic build to process a handful of pngs for her zine. I was instead explaining why Ninja doesn't attempt clever tricks to try to better approximate correctness.
- patrec 6y ago
  > What you wrote is true, but it also seems to me unlikely that the OP is going to set up a sandboxed hermetic build to process a handful of pngs for her zine. But it's trivial! Assuming you fix the OP's Makefile (so much for Makefile syntax usability): # put into Makefile THINGS_TO_CONVERT := $(wildcard *.svg) all: $(patsubst %.pdf,%.svg,$(THINGS_TO_CONVERT)) inkscape $< --export-text-to-path --export-pdf=$@ # put into default.nix with import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/7ad5e816faba3f808e2a8815b14d0f023a4e2160.tar.gz") {}; stdenv.mkDerivation { name = "zine-images"; src = ./.; buildInputs = [ inkscape ]; installPhase = "mkdir $out && cp *.pdf $out"; } Now make sure you have sandbox=true in /etc/nix.conf, run `nix build` in the directory, and boom done: hermetic build of zine images. Good thing too, I got a warning about --export-pdf being deprecated when I ran this. Note that running make or the dependency on make is not explicitly specified, mkDerivation has some basic smarts to figure out from the presence of a Makefile that it should run make. (Hardcoding the version of nixpkgs directly into the default.nix just for demo purposes, better to use niv or similar to manage a json file with versions for you).
  - patrec 6y ago
    Of course we could also get rid of the Makefile and simply add a buildPhase like this: buildPhase = "find -maxdepth 1 -name '*.svg' -print0 | xargs --null -I'{}' -n1 inkscape '{}' --export-text-to-path --export-pdf={}.pdf"; This should also handle filenames with spaces etc. correctly (although I have not tested it).