On Fri, 15 Apr 2016 17:44:54 +0930 Simon Lees <sfl...@suse.de> wrote:
> > > On 04/15/2016 05:40 PM, Andrew Williams wrote: > > 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? > > > That would theoretically break make dist unless you used a script for > that instead of autotools. I use a Lua script for my top level builds. Lua is a dependency of EFL anyway, so it will always be around at build time. Lua is more portable than bash or Windows batch, so that's one script to maintain instead of two (or more). > > 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 > > > -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
