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. -- Jean-Philippe André ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
