On 4 August 2016 at 11:23, Cedric BAIL <cedric.b...@free.fr> wrote: > 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 ! >
Well, yes and no. Let's consider incremental builds only for now, because full build will always take time... so many files to compile. In an ideal world, a .so file timestamp update should not trigger another .so file relink. A change in a function inside Evas (no symbols changed) should not trigger any rebuild outside libevas.so. What happens instead is that all libs depending on evas are relinked, the elm theme is rebuilt, and all widgets previews are relinked as well. Not a single file was recompiled (except the edj ones). Which means the relink happens, even when the symbols table has not changed. A change inside Eina is conceptually a bit trickier as eolian_gen depends on it and everything else depends on eolian_gen's output. So, if by saying "let's speed up make" you mean optimize the dependency resolutions, yes. While that's done by make, the rules are generated by autofoo. Basically if the timestamp comparison was based on only the symbols table and not the actual so file, we would have much faster incremental builds already. But I know I'm just dreaming here... :) -- Jean-Philippe André ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
