On 21 March 2017 at 19:10, Matt Turner <mattst88@xxxxxxxxx> wrote: > On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >> On 21 March 2017 at 18:06, Matt Turner <mattst88@xxxxxxxxx> wrote: >>> (1) Non-recursive automake is necessary for parallel build performance >> Fully agree >> >>> (2) Non-recursive automake is intractably unmaintainable for >>> sufficiently large projects >> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ? > > Not by itself. > > src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million. > Perfect - I can sort out the ~60 gallium Makefiles which constitutes in ~half of mesa quite quickly. As those are sorted I'll look at the more picky ones and ensuring that the contains remain as trivial as possible. Will you/anyone be interested in skimming through the patches ? >> Does it have "dist", "check", "distcheck" or less commonly used > > Our thinking is that by switching to a build system that doesn't > require large amounts of generated code (configure, Makefile.in, etc), > we will stop shipping the code generated by the build system in the > tarballs (which would just be created by git archive). None of that is > set in stone. > Where can I read-up on the discussion ? Would be great if we don't bring back the flex/bison/other requirement for people building from tarballs. Still ... there may be some good arguments against that. >> "ctags" "cscope" targets ? > > I don't know. > >>> And it has momentum: libepoxy already has a Meson build system. Others >>> in the X.Org community are experimenting with it for libinput, Wayland >>> and Weston, and the xserver. >>> >>> All of that makes Meson very compelling. >> That's the thing - I'm never said that it's _not_ a very compelling project. >> I'm saying that it's not there yet - mostly due to the list above. > > Perfect. Since no one claimed it's "there yet" there is nothing to > disagree about. Ack. In the interim we can make our existing build more performant, right ? Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
