On Thu, 14 Jan 2016 17:25:07 +0000 Tom Hacohen <t...@osg.samsung.com> said:
> On 14/01/16 17:18, Tom Hacohen wrote: > > On 14/01/16 01:45, Carsten Haitzler wrote: > >> On Wed, 13 Jan 2016 14:50:20 +0000 Andrew Williams <a...@andywilliams.me> > >> said: > >> > >>> On Wed, 13 Jan 2016 at 13:22 Tom Hacohen <t...@osg.samsung.com> wrote: > >>> > >>>> On 13/01/16 10:54, David Seikel wrote: > >>>>> > >>>> More specifically, I disagree with raster on the build now and remove > >>>> later. Elementary is a completely separate module (to the point that > >>>> it's in its own repo at the moment!). I think it's very reasonable to > >>>> have a "disable" flag for it. It takes time to build elementary, I don't > >>>> want to waste that time either (if I don't want it). > >>>> > >>>> > >>>> > >>> When it comes to build time I want to be able to get it down to an > >>> absolute minimum. > >>> For me this includes being able to build sub-portions at will. > >>> In an ideal world for me the top level would be an agregation that can > >>> build all/any of the children and each library/module that can sanely be > >>> built seperately should be possible. > >>> To facilitate real test driven development it's critical that you be able > >>> to write a test / feature / bug fix and compile for near-immediate > >>> feedback on your work. > >>> > >>> I know it's not something that everyone shares but pushing against this > >>> flexibility is something that I struggle to see value in. > >> > >> actually our issue right now is you cant build a sub-module or sub tree. > >> you always have to build from top. this makes devlopement insanely slow as > >> these builds now always take a minute or so rather than a few seconds - as > >> they walk over everything and "skip". > >> > >> while this allows for much better parallel builds for a full build, it > >> severely hurts development builds (where all u want is to rebuild libevas > >> or libeina and not rebuild everything that also depends on it too). this > >> was a mistake and we need to have the old-school subdir build that elm > >> still has back in efl. > >> > >> eolain is creating issues here in that is touching/modifying files that > >> have not actually changed content and thus causing other regenerations by > >> make etc. > >> > >> we need to fix this. eolain maybe needs to generate the new file to > >> filename.tmp then do a comparison of old filename vs filename.tmp - if > >> they are identical, simply throw away filename.tmp. this will be far more > >> efficient for our builds. > >> > > > > No it's not. Eolian is only regenerating the changes .eo files! It does > > however regen when Eolian files change or eolian_gen changes, which > > means that when you change eolian's source code or eina, it'll regen. > > Sure, we could actually improve it not to "touch" when the output is the > > same. Will get Daniel on it. :) > > Just talked to Daniel about it, and apparently we tried it a few months > ago, but it didn't work out well. Autotools didn't like the fact that > although it asked us to rebuild bla.eo.h it stayed with the same > timestamp... I don't think there's a clean way of doing that. > > Maybe we could just remove the dependency on eolian_gen though, it was > more useful doing development, and not as useful now. This should fix > the issue too. i think that is smart. its stable-ish now and the few changes we make, we can force a rebuild manually. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
