Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ninja: A simple way to do builds

jvns.ca

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Ninja: A simple way to do builds

#81

Post by barumi »

maple3142 wrote: post #68
barumi wrote: post #57

Earlier quoted context omitted.

> Paths containing ':' are also fun. To be fair, anyone who uses reserved/special characters in file names is asking for trouble in pretty much any usage.

But linux filename basically allows any byte sequence except EOF and /, so I think it is "make" fault to not being able to support it. Other proper build tools support it correctly.

> But linux filename basically allows any byte sequence except EOF and / (...)

Could/should/would...

Even though UNIX doesn't impose many restrictions on file names that doesn't mean it's in your best interests to use any weird character in them.

I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"?

Re: Ninja: A simple way to do builds

#82

Post by junon »

barumi wrote: post #59
gravypod wrote: post #47

Earlier quoted context omitted.

I'm not so sure about Nix since it seems much more complex in presentation. The meat and potatoes of Bazel is the BUILD langauge. There may be some warts right now but the community is attempting to address these warts. Difficulty around specifying versions of packages, semantics for building containers, etc. Nix users do not seem to think it's build language is complex. I think Nix might be the worlds best attempt a…

> There may be some warts right now but the community is attempting to address these warts. Some of Bazel's design problems do feel like the outcome of a poorly executed requirements gathering process. Last time I checked, it assumed for some reason that C/C++ interface headers shared a common root folder with libraries, and if that root folder is not the immediate parent folder then it ends up including all files wi…

This, 100%. I had a very long chat with the Bazel team about this in a Github issue. They do not want to budge.

Re: Ninja: A simple way to do builds

#83

Post by junon »

Meson still doesn't get submodules right. So far, CMake gets the closest. The Meson developer is a bit of a jerk about this subject, too - he has a very dogmatic view of how a project should be structured and has designed meson around that.

For example, you cannot have nested subprojects with Meson.

Re: Ninja: A simple way to do builds

#84

Post by barumi »

dasyatidprime wrote: post #77
barumi wrote: post #48

Earlier quoted context omitted.

> There's an even higher probability of Perl being installed You're showing your ignorance there, champ. Make is one of the utilities that's required by the UNIX specification,which means that each and every single UNIX or UNIX-like OS is required to make Make available to users in order to be considered an UNIX. So to make this quite explicit, for starters each and every install of macOS ships with make.

… sort of. Last I checked, the Make features required by POSIX were very anemic. What winds up all over the Web in tutorials etc. is mainly GNU Make, which is extended way beyond that, including in ways which can become practical necessities pretty fast. Which would be why my projects use the “GNUmakefile” file name explicitly, even though e.g. I tend to write to POSIX sh where I can rather than following the “bash s…

> ... sort of. Last I checked, the Make features required by POSIX were very anemic.

You're trying to move the goal post here.

The question is not which obscure feature is made available only by a specific implementation of Make. That's completely besides the point.

The point is that Make is widely available as it is a required component on all UNIX operating systems, and this means that any standard Makefile you might have is assuredly supported on any UNIX installation out-of-the-box.

Re: Ninja: A simple way to do builds

#85

Post by dan00 »

barumi wrote: post #57
dan00 wrote: post #19

Earlier quoted context omitted.

> - if your paths have white space in them, you are generally fucked Paths containing ':' are also fun. That make doesn't handle paths - and most likely other things - as a unit, but just substitutes their string representation into the makefile, is just asking for trouble.

> Paths containing ':' are also fun. To be fair, anyone who uses reserved/special characters in file names is asking for trouble in pretty much any usage.

Having to be aware which character in a path is considered as special by which program, just doesn’t scale very well.

It shouldn’t differentiate what an os and a program consider as a valid path.

Re: Ninja: A simple way to do builds

#86

Post by dan00 »

barumi wrote: post #81
maple3142 wrote: post #68

Earlier quoted context omitted.

But linux filename basically allows any byte sequence except EOF and /, so I think it is "make" fault to not being able to support it. Other proper build tools support it correctly.

> But linux filename basically allows any byte sequence except EOF and / (...) Could/should/would... Even though UNIX doesn't impose many restrictions on file names that doesn't mean it's in your best interests to use any weird character in them. I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"…

The point isn’t if it’s a good idea, but that a program shouldn’t misbehave.

Re: Ninja: A simple way to do builds

#87

Post by maple3142 »

barumi wrote: post #81
maple3142 wrote: post #68

Earlier quoted context omitted.

But linux filename basically allows any byte sequence except EOF and /, so I think it is "make" fault to not being able to support it. Other proper build tools support it correctly.

> But linux filename basically allows any byte sequence except EOF and / (...) Could/should/would... Even though UNIX doesn't impose many restrictions on file names that doesn't mean it's in your best interests to use any weird character in them. I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"…

> I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"?

Yes. It is usually some badly written programs or scripts choke on space, newline other things.

BTW, I would like to impose a restriction that filename must be valid UTF-8 string instead of random bytes.

Re: Ninja: A simple way to do builds

#88

Post by patrec »

evmar wrote: post #73
patrec wrote: post #49

Earlier quoted context omitted.

> 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…

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.

> 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 $
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).

Re: Ninja: A simple way to do builds

#89

Post by patrec »

patrec wrote: post #88
evmar wrote: post #73

Earlier quoted context omitted.

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.

> 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 $ Now make sure you have sandbox=true in /etc/ni…

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).

Re: Ninja: A simple way to do builds

#90

Post by maccard »

antoinealb wrote: post #6

If you don't know it, CMake can use ninja instead of make for compilation so instead of "mkdir build && cd build && cmake .. && make" you can run "mkdir build && cd build && cmake -GNinja && ninja". It feels faster on my side projects (haven't benchmarked it really), but most importantly, when running a parallel build it does not interleave the output of the different steps, making it much easier to read warnings and…

For cross platform-ness you can do

    cmake -H. -Bbuild -GNinja
    cd build && ninja
Post reply on HN