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

[Jakob Bornecrantz]

On Mon, Oct 16, 2017 at 6:58 PM, Scott D Phillips
<scott.d.phillips at intel.com> wrote:
> 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.

Since people are starting to convert more and more to meson support
for this should go in ASAP. So that conversions are done correctly from
the start. I don't think it's smart to wait how many months it will take to
get this upstreamed in meson and then released.

This should have been here from the beginning not some after thought.

Cheers, Jakob.

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