On Fri, 5 Aug 2016 19:00:38 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com>
said:

> On Fri, Aug 5, 2016 at 2:32 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> > worse. try eina. because a .c file changes, eolian_gen is rebuilt. if it is
> > rebuilt then eolian re-generates all .c files. then  these have ot be
> > compiled. then everything relinks...
> >
> > i spend days watching a change inside eina_whatever.c result in this.
> > enough!
> >
> > if i change something in a header that would NEED a rebuild then i'll do a
> > full rebuild of efl THEN. my job as a developer to get that right. the
> > build tools we do have just are not smart enough to detect a change that
> > does really or does not really need a rebuild of everything that depends on
> > it.
> >
> > yes i know in THEORY i changed something that may need it... but i didn't
> > and the tools do not know. this is 99% of the workflow. the relinking also
> > takes forever too.
> 
> Raster, while I know your pain, the change in a base library may
> indeed result in unexpected bugs elsewhere. To optimize that, the
> linker would have to note which symbols changed and then only relink
> binaries using those... kinda of PITA and for real given our heavy
> dependency on other libraries, it wouldn't save us much.
> 
> My advice is to use specific targets during development of core libraries.
> Like:
> 
>     $ make -C src lib/eina/libeina.la
>     $ make -C src bin/eolian/eolian_gen  # just recompile the binary
> and its deps
> 
> If you're doing just eina and don want to waste time with the rest of
> efl that would go in turn.
> 
> If you want to skip regenerating ".eo.c" files because eolian_gen
> changed due changes in libeina.la, you can force a different
> EOLIAN_GEN and _EOLIAN_GEN_DEP to be an older binary (so make will
> check timestamp and say it's up to date):
> 
>    $ make -C src EOLIAN_GEN=/usr/bin/eolian_gen
> _EOLIAN_GEN_DEP=/usr/bin/eolian_gen
> 
> I know it's boring to do those, but you're experienced enough to know
> what would break and all, so these optimizations can be done. However
> not everybody is like that, so if you do what you want for all
> developers you may expect more build breaks :-/

i disagree there. the people who are going to get commit access would/should
know this... :) almost everyone else just does a full build anyway and isn't
doing that much code-wise ESPECIALLY in headers... :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to