On 16 December 2015 at 01:13, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Sat, Nov 28, 2015 at 8:45 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 27 November 2015 at 20:45, Jason Ekstrand <ja...@jlekstrand.net> wrote: >>> On Nov 27, 2015 11:26 AM, "Matt Turner" <matts...@gmail.com> wrote: >>>> On Fri, Nov 27, 2015 at 6:50 AM, Emil Velikov <emil.l.veli...@gmail.com> >>>> wrote: >>>> > On 25 November 2015 at 22:01, Matt Turner <matts...@gmail.com> wrote: >>>> >> On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov >>>> >> <emil.l.veli...@gmail.com> wrote: >>>> > >>>> >>> --- a/src/Makefile.am >>>> >>> +++ b/src/Makefile.am >>>> >>> @@ -23,6 +23,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi >>>> >>> >>>> >>> # XXX: conditionally include >>>> >>> SUBDIRS += compiler >>>> >>> +SUBDIRS += compiler/nir >>>> >> >>>> >> We have a non-recursive build in src/glsl today. I don't want to go >>>> >> backwards. >>>> > Not sure I fully get that can you elaborate ? Are you concerned that >>>> > things won't build in parallel, increasing the compilation times ? >>>> > >>>> > On my dual core system running with -j2 results in approx 15 seconds >>>> > increase. I'm willing to take that trade off for the improved >>>> > readability. What is the difference on your system ? >>>> >>>> src/glsl has single Makefile that builds libglcpp, glcpp, libglsl, >>>> glsl_compiler, glsl_test, libnir, and various test programs, allowing >>>> all of these things to happen in parallel. The Makefile is perfectly >>>> maintainable as it is and there's no advantage of splitting it, >>>> especially when the work has been done to get things to this state >>>> (commits 86d30dea, efd201ca) and NIR was added without an additional >>>> Makefile. >>> >>> I would tend to agree. Making things hierarchical is nice but, >>> unfortunately, autotools makes this and parallelization mutually exclusive. >> >> Actually I have some ancient work where we benefit from both. Namely >> have a single top level Makefile.am, which directly includes the >> subdirectory Automake.mk files, resulting in one big Makefile at the >> very end. >> >> That aside can we get some quantitative representation of the penalty >> you guys see. On my (old) machine the difference is negligible ~15 >> sec of a ~11 minute `make all' and ~16 minute `make distcheck'. > > What happened to this? (Yes, "Busy doing a release" is a valid answer)
There is a question in there for which I was waiting for an answer. Here it is again - split from the rest, with a question mark (silly me). Can anyone confirm how much of a penalty are we talking about (single vs separate makefiles) ? Getting these makefiles benefit from parallelism, whist retaining the split, is reasonably straight forward*. Thanks Emil * Once we find out how to "hack" scons. Will contact Jose and others on the topic shortly. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev