New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite build system in non-autoconf #2503

Open
Ericson2314 opened this Issue Oct 31, 2018 · 35 comments

Comments

Projects
None yet
@Ericson2314
Copy link
Member

Ericson2314 commented Oct 31, 2018

The specific features I am thinking that Autoconf lacks are

  • Windows support (with and without mingw)
  • Outputs Ninja or something similar

Both of these are non essential, but good for various experiments:

  • Windows support obviously allows experimenting with Nix supporting windows. GCC is inadequate because it doesn't offer C++ interopt with MSVC, so Windows's many C++-only APIs are unusable.
  • Outputing a dependency graph allows fun experiments with Recursive Nix (edolstra@1cfdfd7) and ninja2nix (https://github.com/awakesecurity/ninja2nix)

This lowers the list down to Meson and CMake, AFIAK. I prefer Meson because:

  • It doesn't use compiler makefile generation, which avoids a regrettable ninja impurity
  • It's less crufty. CMake became better, but old cmake was bad, leaving a lot of legacy cruft. Meson is a clean slate so there's no minefield of deprecated bad ways of doing things.
  • Full disclosure, I've been working on improving Meson's cross compilation support, so I'm partial to it.

CC @taktoa

@taktoa

This comment has been minimized.

Copy link

taktoa commented Oct 31, 2018

Sadly ninja2nix doesn't really exist -- I tried my best to convert Ninja features into Nix ones using IFD where necessary, but it's just not feasible. If you want to take another crack at it using Recursive Nix, language-ninja is still quite a good library for Ninja-related stuff in Haskell. I think the feature that I couldn't figure out how to compile to IFD was depfile, but I might be mistaken.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Oct 31, 2018

@taktoa But meson doesn't use depfile out of an ideological stance against dynamic dependencies / crawling the filesystem. Problem avoided!

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Oct 31, 2018

So the only Recursive Nix / IFD would be converting the ninja file. Everything inside should be "static Nix".

@taktoa

This comment has been minimized.

Copy link

taktoa commented Oct 31, 2018

This lowers the list down to Meson and CMake, AFIAK. I prefer CMake because:

s/I prefer CMake/I prefer Meson/ presumably?

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Oct 31, 2018

Haha yeah. thanks

@7c6f434c

This comment has been minimized.

Copy link
Member

7c6f434c commented Oct 31, 2018

I think «Windows support with MinGW» is something Autotools have. Or you could say that one of the goals of MSYS is to support Autotools on Windows with MinGW toolchain (and I would say it generally achieves that).

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Oct 31, 2018

Indeed it does. But there's also MSVC and Clang/LLVM. The latter now supports the MSVC++ ABI, after Chrome and Firefox have all pushed hard on it. MinGW has a different C++ ABI (last I checked), and so is only a first class solution for C.

@7c6f434c

This comment has been minimized.

Copy link
Member

7c6f434c commented Oct 31, 2018

I am not sure clang is hard with Autoconf and MSYS. Of course, MSVC is another story (not sure if you actually want to build Nix with it — I agree it is useful for some Windows-only or Windows-first packages).

@edolstra

This comment has been minimized.

Copy link
Member

edolstra commented Oct 31, 2018

The only build system rewrite I'm down with is to a Nix-based build ("nix-make"). Anything else seems pretty much a waste of time to me.

@shlevy

This comment has been minimized.

Copy link
Member

shlevy commented Nov 1, 2018

IMO nix as a build tool to build nix itself should not be a consideration of any work in the near future. At most it should be a happy accidental benefit

@7c6f434c

This comment has been minimized.

Copy link
Member

7c6f434c commented Nov 1, 2018

Would Nix-based Nix build process make compiling Nix for the first time on an exotic (Linux-based) platform more annoying?

@vcunat

This comment has been minimized.

Copy link
Member

vcunat commented Nov 1, 2018

Yes, I expect so, unless we set up some kind of automatic bootstrapping (but that probably won't be easy).

@mstone

This comment has been minimized.

Copy link

mstone commented Nov 1, 2018

@vcunat: on the other hand, nix has somewhat better reflection capabilities than many alternatives. Therefore, even where cross-compiling is hard, perhaps it would still be feasible to use nix to calculate a build script suitable for the target platform.

@edolstra: regarding nix-make: have you done any additional thinking on this topic since a few years ago? (e.g., perhaps in light of https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf being published earlier this year?)

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 1, 2018

So in the imagined Meson (or CMake) + Nix setup, there's really quite little overlap. Most of what Meson does is random domain specific logic for building C/C++ apps. Nix is a perfectly normal C++ program; there's no reason to reinvent the wheel just for Nix-based caching.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 1, 2018

@7c6f434c The conventional way to build Windows apps with clang is actually the clang-cl frontend which exposes a MSVC-style instead of GCC-style CLI. I'm not sure the normal GCC-style even exposes all the necessary options.

@matthewbauer

This comment has been minimized.

Copy link
Member

matthewbauer commented Nov 1, 2018

  • Autoconf should be supported on windows through MSYS.

  • What's nice about autoconf is it just needs bash & gnumake to work. Meson at least pulls in an entire python runtime. We don't want to add anything more to the "common-path" than we already have:

    • coreutils
    • findutils
    • diffutils
    • gnused
    • gnugrep
    • gawk
    • gnutar
    • gzip
    • bzip2
    • gnumake
    • bash
    • patch
    • xz
@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 1, 2018

@matthewbauer

Autoconf should be supported on windows through MSYS.

But GCC doesn't support MSVC C++ ABIs. Many windows APIs are C++, and so I rather unteather us to having to stick to C ones. Who knows how deep we'd have to dig to find the right primitives for sandboxing, for example.

Updated the OP to emphasize this important point.

We don't want to add anything more to the "common-path" than we already have?

I'm confused. This common path sounds like stdenv stuff, but Nix already has non-stdenv library dependencies. Python would just be a build-time dependency, as it is for systemd and other core things that use Meson. Furthermore, if one is really in the pickle, they can stub the build platform in Meson to generate the Ninja files on a different platform than the one where it will be run. (TBH not yet implemented but I think I convinced them to let me do it.)

@coretemp

This comment has been minimized.

Copy link

coretemp commented Nov 2, 2018

I can't really think of any reason as to why we would want to support Windows. Windows has a less efficient kernel to do anything interesting on the platform, so it's not fit to do serious computing. So, all you are doing is porting an interesting program (Nix) to a technically inferior platform (HPC community can tell you more), which is going to increase maintenance cost.

Open-source economics imply that the owner of the project needs to see and trust that someone is going to compensate that maintenance cost or it should be made in such a way that it is easy to rip it out when you get hit by a bus or something (assuming nobody else cares about the feature).

Why did you not just fork Nix and make a Windows port dazzling us with numbers on your build system is faster and more portable, etc.? If the code is that good, I am sure it would get merged in.

@7c6f434c

This comment has been minimized.

Copy link
Member

7c6f434c commented Nov 2, 2018

@coretemp good code with nontrivial trade-offs is quite often not merged, so it is indeed a good idea to have a discussion about limits of likely-to-be-acceptable changes.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 2, 2018

@coretemp so no one in this thread loves Autoconf. The consensus opinion out there is that even on Unix alone, CMake or Meson or whatever else is more maintainable (except if you need to support ancient propriety Unix, which we don't.) Now, I wouldn't push for a rewrite for that benefit alone, but certainly it should nullify any argument that a rewrite is going to hurt regular Unix users.

@coretemp

This comment has been minimized.

Copy link

coretemp commented Nov 2, 2018

@7c6f434c The code can be perfect at implementing something people don't even want. I just don't let that fall under "good code".

"Good code" solves a problem. Here there is, as you say a trade-off, because it is not going to solve the problem. It trades one set of problems (no Windows support) for less portability. That's the main reason this would be controversial. If it was really " good code", portability, readability, code-size, build-time, would not be impacted along with a whole list of other metrics.

I am pretty sure one could build a simple machine learning model that predicts whether a given implementation design of a feature is going to be controversial or not.

With the cross-compilation topic there was a use case for it, so it got in. If @Ericson2314 wouldn't have done it, someone else would have, because porting nixpkgs is a simple way to popularize a particular cloud vendor on a particular instruction set.

Convincing people that have literally built build-systems to do something controversial is never going to work. That's why my issues come with proper rationalization. It is not necessarily a disadvantage that Windows is not supported, but @Ericson2314 implies that this is the case. Forming a correct argument is key to getting changes you want to see in an open-source project. With the proper motivation, you can even convince others to implement the feature for you, because you have informed them that they can improve their business/life by implementing that feature.

@Ericson2314 I like the autotools including autoconf and @matthewbauer seemed to be supportive of autoconf, but I don't particularly care about what other people think when I know better and I consider democratic decisions a failure. You are just alienating the audience by saying things that just aren't true: There is no consensus that CMake is better than autoconf, not in this thread, and certainly not on the Internet.

There is zero chance of convincing me, but luckily for you, you don't have to. If this would have been my project, you would have received a lot less words. All you need to do is either convince the owner of the project, or to fork. It seems you are having little success with the former.

@7c6f434c

This comment has been minimized.

Copy link
Member

7c6f434c commented Nov 2, 2018

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 2, 2018

less portability

Where can't Python run that anyone cares about? The original author may not love Python either, but choose it specifically for build-time portability http://mesonbuild.com/FAQ.html#why-is-meson-implemented-in-python-rather-than-programming-language-x

I agree with @7c6f434c. Any opinionated metric will just flood this thread. The facts are:

  1. Python runs everywhere that Nix supports today
  2. No one needs to read or write Python to use Meson or CMake, so anyone's hatred of that language should not be relevant.
  3. Windows C++ APIs are inaccessible from MinGW/GCC.
@Mic92

This comment has been minimized.

Copy link
Contributor

Mic92 commented Nov 3, 2018

  1. Both meson + cmake can nativly generated compile_commands.json which can be used by IDEs/editors/code analsys to figure out how to compile code
  2. Ninja builds faster then make, at least meson is configuring faster (experienced that when systemd was upgraded)
  3. No longer need to maintain platform dependent code to create executable: https://github.com/NixOS/nix/blob/master/mk/libraries.mk
  4. Better error messages if libraries/headers are not found (relevant for users that have to compile meson nix themselves)
  5. Less flacky build dependency rules: c651b7b
@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 3, 2018

(relevant for users that have to compile meson themselves)

I believe you mean Nix itself, haha. But great list!

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 3, 2018

Maybe the thing to so is just do the conversion in a PR, and let people try out those sweet fast rebuilds for themselves.

@Mic92

This comment has been minimized.

Copy link
Contributor

Mic92 commented Nov 3, 2018

I would not recommend to do that without any blessing from the Nix core team as empirically this could be wasted effort.
Update this was not meant as critic I just wanted to avoid frustration upfront.

@coretemp

This comment has been minimized.

Copy link

coretemp commented Nov 3, 2018

@7c6f434c Yes, you picked out one metric that has no consensus. The rest of the argument still applies.

@Mic92 Creates his own independent argument (with some relevant information, so that's good), but it does not and cannot address the portability side of the equation.

@Ericson2314 Just ignores the portability side of the argument, which is generally not a good way to convince people. And then he alludes to the designers of Meson as if they are an authority 🤣.

@7c6f434c

This comment has been minimized.

Copy link
Member

7c6f434c commented Nov 4, 2018

Ok, just for completeness.

Build time. This is not a single metric but a trade-off, because some ways to get better CPU utilisation for the actual compile can make storage unhappy.

Portability. This is a trade-off, because you need to assign weights to Windows support, OpenBSD support and Linux-on-exotic-CPU support. I wonder if «probability of surviving Apple SDK update» is also a possible part of the portabilty trade-off.

Code-size — is it token count (depending on the parser some things might count or not, so it is not a single objective metric) that ignores cyclomatic complexity? Also, if there is a feature (or platform support) improvement, you won't get a consensus that code size is not allowed to increase.

PS. Speaking of portability — significantly editing GitHub comment after initial creation is not too portable, because it breaks email notifications with high probability. And rendering a GitHub page requires a larger client-side codebase than just handling an email.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 4, 2018

@Mic92 to be clear I was going to make the PR not out of stubbornness, but because I also want to do the windows experiments I deem blocked on this.

@Mic92

This comment has been minimized.

Copy link
Contributor

Mic92 commented Nov 4, 2018

@Ericson2314 I never doubt that.

@volth

This comment has been minimized.

Copy link
Contributor

volth commented Dec 2, 2018

The only build system rewrite I'm down with is to a Nix-based build ("nix-make").

Using nix-make raises question about changing the embedded imperative language (to write buildPhase, installPhase) from bash to something more portable.

bash is too weird on Windows (it translates delimiters : <-> ; and \ <-> / as it likes and often incorrectly, for example cl /nologo run from bash will be converted to cl c:\msys64\nologo, etc).

Currently I am using perl as stdenv.shell on Windows/MSVC, but it has some drawbacks:

  • it need perl's libraries to perform basic operations like file copy
  • simple operations like accessing environment or launching external programs are much more verbose than in bash (system("make PREFIX=$ENV{out}") == 0 or die $! vs. make PREFIX=$out)
  • problems with Unicode in file names, command-line params and environment variables
  • there are too many perl-haters.

Lua, Red or Python might be alternatives here, or, well, cmake...

@volth

This comment has been minimized.

Copy link
Contributor

volth commented Dec 2, 2018

I can't really think of any reason as to why we would want to support Windows. Windows has a less efficient kernel to do anything interesting on the platform, so it's not fit to do serious computing. So, all you are doing is porting an interesting program (Nix) to a technically inferior platform (HPC community can tell you more), which is going to increase maintenance cost.

For example, imagine a browser automation / screenshot farm for testing a website.
Nix is nice to compile 100 different browsers and deploy them.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Jan 5, 2019

Started working on a meson version here in #2613

@bhipple

This comment has been minimized.

Copy link
Contributor

bhipple commented Jan 15, 2019

Please don't make Nix depend on nix-make; doing so would make bootstrapping a raw from-source build of Nix significantly more complicated, and we'd have to continue to maintain all of the autotools build scripts for that purpose. This is not just a considerations for "exotic linux distros" but also for standard Debian or CentOS packaging as well, and a thorn in the side of initiatives like https://reproducible-builds.org/ that are trying to build everything from source with as few pre-built binaries as possible.

I can understand @NixOS/nix-core not wanting to spend their time shaving the build-system yak. Autotools seems to be doing OKish as it is, but if @Ericson2314 wants to do it it seems like a nice thing for the community and I hope it gets a serious review/consideration! Either cmake or meson would be faster to compile, have better error messages, and support things like clang compilation databases for YCM and other LLVM tools. Modern C++ build system tooling has come a long way in the last decade and it'd be nice to take advantage of it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment