On Tue, 2 Aug 2016 10:00:16 +0930 Simon Lees <sfl...@suse.de> said: > > > 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 do. i do. it STILL takes multiple minutes as opposed to under 5sec like it used to. > -- > > Simon Lees (Simotek) http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adeliade Australia, UTC+9:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > -- ------------- 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
