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. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
