<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Dec 16, 2018 at 1:49 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1. Build creation command recovery. With autotools, "head config.log"<br>
will tell you how you configured it. This is important when things get<br>
screwed up, and so has to be available in plain text somewhere. There<br>
are a variety of other occasions where this can be useful -- debugging<br>
someone else's build, creating a second build for yourself with a few<br>
options changed, etc.<br></blockquote><div><br></div><div>I'm not sure that this is necessary but I agree that it is useful.  I think Dylan said someone was working on this?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. Summary at the end. This is not strictly an autotools-specific<br>
issue, but rather how mesa has used it. That summary at the end is<br>
very useful to make sure you (or someone you're helping) hasn't<br>
screwed something up.<br></blockquote><div><br></div><div>Run "meson configure" with no options.  It will dump out a full configuration.  Sure, it's not the same format but, unless I'm misunderstanding something, all of the information from the old summary and more is available there.  Or are you concerned with various derived or auto-configured values?  Or is it your concern that it get dumped out at the end of a configure rather than having to ask for it?  It'd be helpful if you'd be more specific about what you want than "the autotools thing".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. Have a configure helper which makes it look like autotools.<br>
Everyone knows how to use autotools, in part because it's so very easy<br>
to use. No one wants to figure out how to operate some random<br>
project's build system (and while meson may have world-dominating<br>
aspirations, it's certainly not there yet). This is one of the reasons<br>
I avoid doing anything of substance with cmake-based projects. A few<br>
bits which ought to work: "./configure --help", "./configure<br>
--with-gallium-drivers=..." and so on, similar to the existing logic,<br>
"./configure CFLAGS=-O0" and so on. Those environment variables need<br>
to be baked into the build, and it should be able to bake in things<br>
like PKG_CONFIG_PATH in a way that affects meson's operations, not<br>
just the build-time bits. This should default to a particular build<br>
directory (perhaps creatively called "build"), with some way to<br>
specify an alternate (e.g. add a --builddir=...). I think it's fine to<br>
have a dummy Makefile generated in this case which just says "run<br>
ninja" without actually running it.<br></blockquote><div><br></div><div>On the surface, I think this is a bad idea.  We currently have two build systems that duplicate all these options and information and you're effectively asking for a third.  Perhaps we could write a bit of python which autogenerates it from meson_options.txt in which case it might be ok.  However, I'm not at all a fan of duplicating all the information in a shell script just so people can run ./configure instead of calling meson directly.<div><br></div><div>For whatever it's worth, I used to also think this 
would be a good idea.  More recently, however, I've come to the 
conclusion that it'd just be a crutch to help people continue pretending
 meson doesn't exist.  If we provide ./configure and Make what 
are people going to want next?  In-tree builds?  Also, when are we going
 to get to delete the ./configure script?  Probably never.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. No matter what happens to the system, re-running "ninja" or<br>
"configure" should not cause failures. This can't always be prevented<br>
(bugs happen, I get it), but you get like one screwup every 5 years --<br>
it should be avoided as much as possible. If the solution is that the<br>
tool re-runs itself using the old configuration, that's fine -- but it<br>
can't just die saying "oh no, you're screwed", which it currently does<br>
when updating meson on the system.<br></blockquote><div><br></div><div>Yes,I agree that this is a failing of meson and needs to be sorted.  Meson could do a much better job of reconfiguring by itself when it detects an incompatible update.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
5. Cross-files are a clever way of solving the issue by offloading it<br>
as "not-my-problem". And the configuration for cross-compiling project<br>
A is going to be identical to project B. I understand all this.<br>
However in declaring it as "not-my-problem", meson makes it the user's<br>
problem. These files are currently not shipped as part of<br>
cross-compiling setups, and asking each user to figure out how to set<br>
them up is excessive -- cross builds are complex enough, and this is<br>
yet-another thing in the path to success. The configure wrapper should<br>
be able to take the standard parameters (--build, --host, etc) and<br>
have it work (e.g. by generating a cross-file on the fly).<br></blockquote><div><br></div><div>I have seen multiple times now people vastly over-simplify how "automatic" autotools makes cross-building.  The crossfile contains a lot more than just --build and --host; it has actual paths to compilers and pkg-config, extra options, and a few other things.  Then how does autotools make it so simple?  Because distros ship patched versions of autotools with the distro-specific bits hacked in.  On Fedora, for instance, they've hacked it up so that --prefix=/usr on a 64-bit system automatically implies --libdir=/usr/lib64 even though libdir is usually ${prefix}/lib.  Where you find the gcc compiler for ppcle64 on a x86_64 system, for instance, is also highly distro-specific and requires patching.  The "correct" solution here is for each distro, when they package meson, to also package a set of appropriate cross files that instructs meson how to cross build for each platform on that distro.  They should be easy enough to generate with a tiny bit of python, perl, or shell code that's aware of how the distro lays things out on the file system but it has to be done by the distro, not meson.</div><div><br></div><div>This also means that your suggestion of just making the ./configure wrapper generate the cross file isn't really all that practical.  I suppose you could, in theory, have a script which attempts to auto-detect it by crawling the file system and tries to find the compilers etc. based on known distros.  However, any such attempt would be complicated, fragile, and have unpredictable error modes when some unknown distro is encountered.</div><div><br></div><div>Sorry if I don't buy the "just make it look like autotools" argument.  With X, Wayland, Weston, systemd, and many other system-level Linux projects moving to meson, it may not yet be mainstream but I don't think it's ignorable anymore.<br></div><div><br></div><div>--Jason<br></div></div></div>