[Mesa-dev] [PATCH 1/2] meson: provide Makefile.sources variables to meson build

[Scott D Phillips]

Dylan Baker <dylan at pnwbakers.com> writes:

> Quoting Scott D Phillips (2017-10-16 10:04:45)
> > Dylan Baker <dylan at pnwbakers.com> writes:
> > 
> > > Quoting Jakob Bornecrantz (2017-10-14 13:03:14)
> > > > On Sat, Oct 14, 2017 at 1:36 AM, Dylan Baker <dylan at pnwbakers.com> wrote:
> > > > > I'm not sure about this approach, we would need a way to add
> > > > > depends to meson,
> > 
> > 'add depends' meaning having a way for the build steps themselves to
> > depend on modifications to Makefile.sources files? If so, I think
> > there's a pretty good solution in:
> > 
> > https://github.com/mesonbuild/meson/pull/2490
> > 
> > It doesn't have anything to do with makefiles or anything, but just
> > adds a regenerate-the-build-steps dependency on scripts and script
> > arguments to run_command() that are within the srcdir. I would say
> > it is a bug that that functionality is missing as it is.
>
> I agree, and if upstream won't take the module approach this is
> probably the best solution, unless the community decides the
> duplication is okay in the long term. That's what Xorg did.
>
> > 
> > > > > but I'm also worried that calling make adds another dependency
> > > > > that could be problematic for windows,
> > 
> > afaict, getting a copy of make on windows isn't really too odious,
> > the problem is just that using autotools sucks really bad there.
> > 
> > > > > and I really don't like the idea of having a half-and-half
> > > > > approach with the sources.
> > 
> > I agree and many more patches are in order if we go this route. I
> > just didn't want to do the work of making those if the idea itself
> > didn't sound good to folks.
> > 
> > > > > Here's what I've been playing with:
> > > > > https://github.com/dcbaker/meson/tree/make-import-module
> > > > > https://github.com/dcbaker/mesa/tree/wip/meson-makefile-sources
> > > > >
> > > > > How would you feel about that?
> > 
> > I would suggest changing the naming from a "Makefile parser" to an
> > "Automake Makefile parser". That way your parser goes from
> > very-incomplete to almost-complete for the source format.
> > 
> > How confident are you that this extension would be accepted in
> > meson? I got the notion from somewhere that dealing with makefiles
> > is an antigoal for meson, but maybe that's not right.
>
> I'm not extremely confident of anything with meson, upstream can be a
> bit odd, but I'm more confident of getting a module in than anything
> else. I think it's pretty close to proposing, but I wanted to get a
> patch for mesa so I could point to it and say, "look, this is why we
> need this".
>
> What they are extremely adverse to is a make backend, whether they
> would accept this parser (under any name) I don't know yet, but I'm
> going to make a heck of an argument for it.

Cool, I agree trying to get your parser upstream is the way to go here.

> > > > Couldn't you just use the Makefile parser José wrote for the
> > > > scons build, that would avoid running make and waiting for a new
> > > > version of Meson. Or is there something it is lacking?
> > > >
> > > > We could start out with our own Makefile parser and then move
> > > > onto one in Meson once it is upstreamed and that version of
> > > > meson is commonly available?
> > > >
> > > > Cheers, Jakob.
> > >
> > > In the short term I don't know how much it really hurts to
> > > duplicate the sources in meson vs reading the makefiles,
> > 
> > That's the question really. If nobody cares about the duplication,
> > then this patch or any other like it probably isn't worth it.
> > 
> > I've seen a lot of patch reviews with "you forgot to update build
> > system X" though. I think it's worth our collective time to
> > consolidate the number of places that an average patch needs to
> > touch build system configuration. (Without turning them all into
> > Frankenstein build systems obviously).
> > 
> > > I also haven't had a chance to look at what Jose did in scons, but
> > > if upstreaming fails that is probably a good starting point. I'd
> > > like to try to get something upstream rather than hacking around
> > > meson, since that has been very successful in the past. I should
> > > also point out that meson's LLVM handling is due for a pretty
> > > major overhaul (patches waiting more review and merge), and that
> > > we really want that support anyway (among other things meson's
> > > LLVM inserts -L/usr/lib into your linker args, and as of 0.43
> > > lacks static/dynamic linking options. There are also some features
> > > that are in 0.43 (we currently support back to at least 0.42, I
> > > haven't tested further back than that) that we will need to work
> > > on windows (our workarounds involve using touch). There's also
> > > still a lot of work to do to get our meson build system up to the
> > > quality of our autotools and scons build systems, so I think we
> > > have some time before we need to worry really hard about it.
> > >
> > > Dylan
> > > _______________________________________________
> > > mesa-dev mailing list
> > > mesa-dev at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev