On Fri, 5 Aug 2016 13:37:12 +0900 Jean-Philippe André <j...@videolan.org> said:
> 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. worse. try eina. because a .c file changes, eolian_gen is rebuilt. if it is rebuilt then eolian re-generates all .c files. then these have ot be compiled. then everything relinks... i spend days watching a change inside eina_whatever.c result in this. enough! if i change something in a header that would NEED a rebuild then i'll do a full rebuild of efl THEN. my job as a developer to get that right. the build tools we do have just are not smart enough to detect a change that does really or does not really need a rebuild of everything that depends on it. yes i know in THEORY i changed something that may need it... but i didn't and the tools do not know. this is 99% of the workflow. the relinking also takes forever too. > 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 -- ------------- 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
