Dylan Baker <dy...@pnwbakers.com> writes: > Quoting Scott D Phillips (2017-10-16 10:04:45) > > Dylan Baker <dy...@pnwbakers.com> writes: > > > > > Quoting Jakob Bornecrantz (2017-10-14 13:03:14) > > > > On Sat, Oct 14, 2017 at 1:36 AM, Dylan Baker <dy...@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@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
