On Thu, Apr 14, 2016 at 8:30 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 15 Apr 2016 11:51:56 +0900 Jean-Philippe André <j...@videolan.org> > said: >> On 15 April 2016 at 08:08, Cedric BAIL <cedric.b...@free.fr> wrote: >> > cedric pushed a commit to branch master. >> > >> > http://git.enlightenment.org/core/efl.git/commit/?id=4c921204575a8bc96d9449810ab963d0461c6152 >> > >> > commit 4c921204575a8bc96d9449810ab963d0461c6152 >> > Author: Cedric BAIL <ced...@osg.samsung.com> >> > Date: Wed Apr 13 15:55:31 2016 -0700 >> > >> > evil: make it possible to build the library alone. >> > >> > So I have been battling with autotools on this for a full week now, >> > and what we want is basically impossible. A.k.a. one file definition >> > and possibility to do a full build or just a partial build of efl. >> > Even moving to just partial build require to land a massive patch that >> > change everything in our build system and this is just not a road I >> > want to take. >> > >> >> This patch will do for now. >> >> For reference, if one day automake allow the use of any kind of variable >> > (autoconf AC_SUBST expansion or $()) in the _SOURCES parameter, it will >> > be possible to fix. Alternatively if they allow to build subdirectory >> > before they do BUILT_SOURCE, it would make it possible to incrementaly >> > move to only partial build. In the mean time, a less problematic >> > solution >> > is to duplicate source code. >> > >> >> So if I understand correctly, this means every change to >> src/Makefile_XXX.am needs to be reflected in src/lib/XXX/Makefile.am?
Yes, no way around using autotools. It is a limitation as said in the commit to how _SOURCES is handle. Now, what we can do is a separate script in our autogen.sh that would generate the Makefile.am and still have the Makefile.am in our git tree. That is for now the best solution I can think of considering all the constraint I learned about m4 and autotools. >> That's not a very elegant solution, but I understand there is no better way. >> Should we or can we have automated builds on Jenkins for those partial >> builds? This would be a very good idea ! > we will then ultimately move back to a recursive subdir build, slowly one > lib/.bin/whatever dir at a time then. it's slower for rebuilds but massivewly > faster for development which is where you should be spending the majority of > your time. having to wait 1-2 mins for a "make && sudo make install" just to > see if your 3 lines inside some eina file or eo file works... is massively > counter-productive. full rebuilds can be scripted and automated to go a few > times a day for full checks. but many devs are now complaining of the workflow > hit of a full rebuild/relink every small change to a low level lib file. :-( > it > has been pissing me off now for a year or 2. it's getting worse. That is not going to happen soon. After my attempt to have both top and specific Makefile.am with no code duplication, I started working on just splitting it. That didn't work either as before going in any sub tree, everything that is in BUILT_SOURCE as to be build. Basically, I would have to do the split in one huge swoop. Considering how complex our build system is, I really don't feel confortable doing it any time soon. The best path forward that I can see now is to : - Maybe introduce an pre script to autotools that generate the Makefile.am - Continue splitting each library and binary - When we are confident that every combination is well tested and covered, we can maybe split the top Makefile and only rely on the sub one. This is not going to happen in a hurry and I have now to move to other tasks as i have spend already way to much time on this ! Cedric ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
