On Mon, Aug 1, 2016 at 5:50 PM, 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: >> >>>> 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)
Yes, only way around that would be to introduce our own pretool to fill the Makefile.am with the proper list of files. The rest are autotools limitation. > - it recompiled entirely each "module" (no incremental build after the main > build was run) Yes, that's due to the object naming convention used by autotools which use the full relative path, but subsequent build would not require a full rebuild. This is non fixable. > I know I broke the per directory build a few times, no one even said > anything. That's how much it was used. Pretty much my point. Also I have run some benchmark, if we do go back to multiple Makefile (If that was even doable), we will have a total build time when nothing has changed significantly increased as our issue is in parsing Makefile (9s on my laptop into parsing) and splitting Makefile will result in duplicated boilerplate to parse. It also means that as long as we have that many files, modules and libraries, this parsing will be there and will likely still cost us that much. I have started looking at GNU make and I think there is room for serious improvement in their parsing code. Will see if I can manage something in the comming weeks. As for the reason why we can't move to split Makefile.am, it's pretty simple. It has to be done in one move due to how autotools handle sub directories and dependencies. For anyone who has looked at our build system, this is just litterally insane to do. We have to face it our toolkit has grown big enough that any build system we use is going to be seriously complex, hard to maintain and slow (Before we didn't notice that slowness as it was spread on 10 differents run of make). Reducing options and merging library will just marginally help. I will not be the one converting it to a single Makefile and if someone is crazy enough to do it, be my guest ! All the above also apply to a conversion to cmake. Pretty sure it will not help that much. If you want to speed up things, speed up make ! Have fun, -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
