On Tue, 2 Aug 2016 11:36:49 +1000 David Seikel <onef...@gmail.com> said:
> On Tue, 2 Aug 2016 09:50:13 +0900 Jean-Philippe André > <j...@videolan.org> wrote: > > > On 2 August 2016 at 09:30, Simon Lees <sfl...@suse.de> wrote: > > > > > > > > > > > On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote: > > > > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL > > > > <cedric.b...@free.fr> > > > said: > > > > > > > >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen > > > >> <t...@osg.samsung.com> > > > wrote: > > > >>> On 01/08/16 17:07, Stefan Schmidt wrote: > > > >>>> Hello. > > > >>>> > > > >>>> The extra Makefiles to allow building some libraries > > > >>>> separately have been broken for a while now. Nobody updated > > > >>>> them when changes > > > happened. > > > >>>> The normal problem when trying to have two build setups in one > > > >>>> tree. > > > >>>> > > > >>>> I just gave it another go and ecore, edje, eio and elementary > > > >>>> failed > > > for > > > >>>> me. > > > >>>> > > > >>>> Many of them also fail from a tarball build because they > > > >>>> include Makefile_Eolian_Subbuild_Helper.am which never makes > > > >>>> it into the > > > tarball. > > > >>>> > > > >>>> cd ../../.. && /bin/sh > > > /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing > > > >>>> automake-1.15 --gnu src/lib/ecore/Makefile > > > >>>> configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is > > > >>>> deprecated, and its use is discouraged. > > > >>>> configure.ac:284: You should use the Autoconf-provided > > > 'AC_PROG_MKDIR_P' > > > >>>> macro instead, > > > >>>> configure.ac:284: and use '$(MKDIR_P)' instead of > > > >>>> '$(mkdir_p)'in your Makefile.am files. > > > >>>> automake-1.15: error: cannot open < > > > >>>> src/Makefile_Eolian_Subbuild_Helper.am: No such file or > > > >>>> directory Makefile:1644: recipe for target 'Makefile.in' failed > > > >>>> make: *** [Makefile.in] Error 1 > > > >>>> > > > >>>> > > > >>>> All in all I think it would make sense to remove this extra > > > >>>> Makefiles all together and stay with the one big Makefile > > > >>>> build for 1.18. I know the build times are frustrating and we > > > >>>> might want to switch back to a non aggregated Makefile to > > > >>>> allow easier rebuilds of specific libs > > > only. > > > >>>> > > > >>>> Having a second, non working, build setup in tree for the > > > >>>> release is something I would like to avoid though. > > > >>>> > > > >>>> Comments? > > > >>> > > > >>> That's what I've been saying since they were introduced. Two > > > >>> build systems is a bad idea, we should just stay with single > > > >>> build until we move to split. > > > >> > > > >> And it also make clear that nobody really care about per > > > >> directory build. Anyway. It has been now removed by commit > > > >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb. > > > > > > > > actually that's wrong. i have used them.. BUT when i use them it > > > > goes and rebuilds AGAIN in that dir and doesn't use my existing > > > > toplevel build. > > > that is > > > > SUPER annoying. i've also found them to be at least partially > > > > broken. we discussed this long ago and no one wanted 2 build > > > > systems. almost > > > everyone > > > > except you wants per-directory build back again and there just is > > > > no > > > sane way > > > > to have both with a single file. the subdir builds needed to be > > > > the ONLY > > > builds > > > > available. > > > > > > > > > > As long as distro people can still build everything from one > > > command. > > > > > > If the subtree builds are just to save developer build time, why > > > don't you all just install ccache and be done with it, ccache > > > significantly reduces my efl rebuild times. > > > > > > We use it :) A basic incremental build is still very slow (touch an > > file in eina to see...). > > > > The problem with the per-directory build was two-fold: > > - separate makefiles (totally unmanageable) > > - it recompiled entirely each "module" (no incremental build after > > the main build was run) > > > > I know I broke the per directory build a few times, no one even said > > anything. That's how much it was used. > > What I tend to do in big projects is to create per directory builds, > then a top level script that calls the per directory builds if needed. > That's the best of both worlds, without having two build systems. that is what per dir makefiles do. subdir builds. you dont need scripts. our isssue is we have a single makefile in src/ and thats it. (well another in toplevel that recurses to src etc.). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
