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. -- Tom. ------------------------------------------------------------------------------ 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
