Hey Dylan, Dylan Baker wrote on 21.03.2017 18:34: > Quoting Kai Wasserbäch (2017-03-21 09:50:52) >> I've just a few points, since I'm not too enthused by the prospect of having to >> deal with yet another build system with yet another slightly different syntax. >> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper >> involved with Mesa and their opinion is what matters in the end. Anyway, here >> goes nothing. >> >> This might be a dumb question but isn't Meson (through wrap files) one of the >> build systems that download crap from all over the internet silently? Ie. making >> a packager's/distribution's life hell? There is >> <https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source> >> but that seems to imply a silent fallback to downloading stuff. I would rather >> have a configure step that fails if a dependency is not met instead of building >> something that can't be distributed. Or is there a magic "--distribution-build" >> flag? If there isn't I would rather see a switch to CMake (as others have >> pointed out in this thread: many projects in the vicinity of Mesa already use >> CMake), but I get that there's a lot of hate for CMake (even though the Meson >> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch >> would be unlikely. > > I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly > aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs > where it's not. What I would expect if the windows guys wanted to use wrap is > that we would have something like this: > > if host_machine.system() != 'windows' > dep_zlib = dependency('zlib', version : '>1.0.0') > else > subproj_zlib = subproject('zlib') > dep_zlib = subproj_zlib.get_variable('zlib_dep') > endif > > Which would make the dependency a hard requirement for non-windows system (i.e. > the configure fails if zlib isn't found *except* on windows), and windows could > fall back to wraps. > > I have no plans to implement wrap for mesa in the port I would do, and would NAK > any patches that used wrap on Linux or BSD. The windows devs can make their own > choice on how to handle dependencies (I have no idea what their development > environment looks like and don't want to make that choice for them). I agree > with you it's not the way that Linux or BSD works, we have competent package > management solutions without the need to automatically download sources. I hope the rest of the Mesa project would follow such a rule. Because if there's something I absolutely hate about all those "new" build systems, then it's their tendency to just download stuff and build/include that. This seems to have risen with Node and now spread into Rust and other parts of the FLOSS eco-system. > As for cmake. I've written enough cmake in piglit to last me a lifetime, meson > and cmake are the difference between python and perl, there may be some > superficial similarities, but they are *not* the same. One of the things I'll > reiterate that impressed me the most about meson is that it's syntax is simple, > not Turring-complete, and opinionated. > > In fact, piglit is the best reason not not use cmake I can come up with. There > is an (admittedly clever) hack to allow building tests for each of the API's > supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for > each API, which means you can't put things in the tests directory that can only > be run once. Every time I try to make changes to the Cmake I spend about an hour > trying to figure out why some code I've implemented doesn't work, only to > remember that. Build systems aren't programming languages, they shouldn't be > interesting, they should be declarative; cmake is a full scripting language with > enough warts to make bash look cuddly. Hm, I have written a lot of CMakeFiles.txt and so far I've always been rather happy with them. Not sure what Piglit is doing though. >> Dylan Baker wrote on 16.03.2017 22:25: >>> Why bother, and why would we want this? >>> >>> First it's written in python, which means the potential developer base >>> is massive. And it provides a recursive view for humans, but a >>> non-recursive view for the system. This is the best of both worlds, >>> humans can organize the build system in a way that makes sense, and the >>> machine gets a non-recursive build system. It also uses ninja rather >>> than make, and ninja is faster than make inherently. >> >> Well, CMake (and probably others), see >> <https://cmake.org/cmake/help/latest/generator/Ninja.html>, can use/generate for >> ninja too. > > Sure, I think we've gone over this in the rather long thread, ninja is really > just a "nice to have" since it's faster than make. The real advantages are: > 1) one build system for linux and windows (reducing from 3 to 2 build systems) CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the Android eco-system already (<https://developer.android.com/ndk/guides/cmake.html>), which might mean it could be easier for the Android downstreams of Mesa? Not sure on that though. > 2) meson much simpler than autotools, scons, or (especially) cmake OTOH CMake gives you CTest/CDash (<https://cmake.org/cmake/help/latest/manual/ctest.1.html>), CPack (<https://cmake.org/cmake/help/latest/manual/cpack.1.html>), dependency visualisation (<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html>) and many other things for (basically) free. Maybe that warrants some complexity? > 3) recursive meson files, flat ninja file. IIRC you would also get the same with CMake if you target Ninja. >>> Meson is also a >>> simpler syntax than autotools or cmake it's not Turing Complete by >>> design nor does it expose python, again, by design. This allows meson >>> itself to be reimplemented in a another language if python becomes a >>> dead-end or a bottle-neck. It also makes it much easier to understand >>> what the build system is doing. >>> >>> What's different about using meson? >>> >>> Well, apart from a faster builds and less magic in the build system? The >>> configure flags are different, it uses -D<opt>=<value> more like cmake >>> than the --enable or --with flags of autotools, although oddly it uses >>> --prefix and friends when calling meson, but not with mesonconf, there's >>> a bug opened on this. Meson also doesn't support in-tree builds at all; >>> all builds are done out of tree. It also doesn't provide a "make dist" >>> target, fortunately there's this awesome tool called git, and it >>> provides a "git archive" command that does much the same thing. Did I >>> mention it's fast? >> >> Nothing against git archive, but you then would need to maintain .gitattributes >> in addition to the build system input files, correct? Right now the distribution >> rules are just in the Makefile.in files, making them more visible and less >> easily forgotten. > > I've never had to use gitattributes for anything, are you thinking for setting > export-ignore and export-subst? Yep. AFAICT we have several files which aren't distributed if you do "make dist". Those would need to be excluded from a tarball built with git archive as well. AFAIK that's done through having .gitattributes files in the tree. Anyway, I don't want to bikeshed here, so I'll be silent as long as any possible future build system doesn't download stuff behind my back. Thanks for your reply! Cheers, Kai
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
