On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dylan@xxxxxxxxxxxxx> wrote: > Quoting Rob Clark (2017-03-22 10:07:54) >> I guess an interesting question (from someone who doesn't know meson >> yet) would be whether meson could slurp in the Makefile.sources type >> stuff that we have, which are shared so far between >> android/scons/autotools (and for the most part, kept developers from >> having to care *too* much about the different build systems) > > Jason and I have talked about that too. I'd suggested that we could write a > module for meson to read makefile.sources (since we're surely not the only > project that would benefit from such a module), except that android is moving to > blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't > support using makefile.sources, so it seems somewhat moot in a world of > blueprint for android, meson for *. I guess even if it is only a temporary thing, something that could slurp in Makefile.sources seems like it would be useful for a transition period. I'm not totally up to speed on android/blueprint stuff.. but even some simplified or different "here-are-my-sources" type file that could be shared across build systems would be useful. Meson sounds a bit more extensible so maybe there is some potential to adapt to whatever android forces on us ;-) > I don't think that meson should try to generate blueprint files, since blueprint > is itself a metabuild system that generates ninja files, and is self > boot-strapping Go code. I don't know if the community is going to want blueprint > to live in repo either, since one actually writes Go code for the build system. > (I'm not objecting prematurely, I'm just pointing out that the design is > significantly different the Android.mk, and the community will probably want to > re-evaluate) > > If android doesn't mandate a migration to blueprint, or blueprint does handle > makefile.sources (I don't think it does), I'd be happy to propose a module for > meson that could read makefile.sources, and write said module, and get said > module upstream. I guess from my PoV with my developer hat on, as long as simple things like adding/removing src files to an existing .so or .a require just editing one build file for all build systems, that pretty much guarantees that I don't forget to update one and anger windows/android/$other_random_thing builders ;-) (with my $enterprise_distro hat on, I think *probably* the main thing is that we don't drop autotools build support before gnome/gstreamer/etc.. not 100% sure about the py3 dependency but I guess if we aren't the only one that needs it to build, that helps..) BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
