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

[Dylan Baker]

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.

> 
> > > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171016/a3443ee7/attachment.sig>