I may be duplicating what raster said but to avoid the makefile duplication can we not move them to individual build only and ship top level bash&win-batch&whatever scripts to simply iterate when a full build is needed?
I'm working on the idea of partial builds or testing within EDI but being per-lib will be much more helpful in the meantime. Thanks, Andrew On Fri, 15 Apr 2016 at 04:31, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 15 Apr 2016 11:51:56 +0900 Jean-Philippe André <j...@videolan.org> > said: > > > Hi Cedric, > > > > 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? > > > > 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? > > 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. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
