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

Scott D Phillips scott.d.phillips at intel.com
Mon Oct 16 17:04:45 UTC 2017


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.

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

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


More information about the mesa-dev mailing list