Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[The Rasterman]

On Fri, 5 Aug 2016 19:00:38 -0300 Gustavo Sverzut Barbieri 
said:

> On Fri, Aug 5, 2016 at 2:32 AM, Carsten Haitzler  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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Gustavo Sverzut Barbieri]

On Fri, Aug 5, 2016 at 2:32 AM, Carsten Haitzler  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 :-/



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Simon Lees]

On 08/05/2016 02:07 PM, Jean-Philippe André wrote:

>> All the above also apply to a conversion to cmake. Pretty sure it will
>> not help that much. If you want to speed up things, speed up make !
>>
> 
> Well, yes and no. Let's consider incremental builds only for now, because
> full build will always take time... so many files to compile.
> 
> In an ideal world, a .so file timestamp update should not trigger another
> .so file relink.
> A change in a function inside Evas (no symbols changed) should not trigger
> any rebuild outside libevas.so.
> What happens instead is that all libs depending on evas are relinked, the
> elm theme is rebuilt, and all widgets previews are relinked as well. Not a
> single file was recompiled (except the edj ones). Which means the relink
> happens, even when the symbols table has not changed.

From my experience with cmake it seemed that it managed this much
better, ie internal evas changes wouldn't trigger rebuilds of other
parts. Our main cmake project was a bunch of static libs (each with its
own subproject file), that were all linked together into either an
executable and it seemed to handle that in a sane way, ie changing a c
file in eina would not trigger a complete rebuild of everything but if
you picked the wrong public header and changed that it probably would.

Unfortunately I don't know if i have time to do the port or enough
autofoo knowladge to be able to do it but maybe i'll give it a shot.

> 
> A change inside Eina is conceptually a bit trickier as eolian_gen depends
> on it and everything else depends on eolian_gen's output.
> 
> So, if by saying "let's speed up make" you mean optimize the dependency
> resolutions, yes. While that's done by make, the rules are generated by
> autofoo. Basically if the timestamp comparison was based on only the
> symbols table and not the actual so file, we would have much faster
> incremental builds already.
> 
> But I know I'm just dreaming here... :)
> 

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[The Rasterman]

On Fri, 5 Aug 2016 13:37:12 +0900 Jean-Philippe André  said:

> On 4 August 2016 at 11:23, Cedric BAIL  wrote:
> 
> > On Mon, Aug 1, 2016 at 5:50 PM, Jean-Philippe André 
> > wrote:
> > > On 2 August 2016 at 09:30, Simon Lees  wrote:
> > >> On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> > >> > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL 
> > >> said:
> > >> >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen 
> > >> wrote:
> > >> >>> On 01/08/16 17:07, Stefan Schmidt wrote:
> > >>  The extra Makefiles to allow building some libraries separately
> > have
> > >>  been broken for a while now. Nobody updated them when changes
> > >> happened.
> > >>  The normal problem when trying to have two build setups in one
> > tree.
> > >> 
> > >>  I just gave it another go and ecore, edje, eio and elementary
> > failed
> > >> for
> > >>  me.
> > >> 
> > >>  Many of them also fail from a tarball build because they include
> > >>  Makefile_Eolian_Subbuild_Helper.am which never makes it into the
> > >> tarball.
> > >> 
> > >>  cd ../../.. && /bin/sh
> > >> /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> > >>  automake-1.15 --gnu src/lib/ecore/Makefile
> > >>  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is
> > deprecated,
> > >>  and its use is discouraged.
> > >>  configure.ac:284: You should use the Autoconf-provided
> > >> 'AC_PROG_MKDIR_P'
> > >>  macro instead,
> > >>  configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in
> > your
> > >>  Makefile.am files.
> > >>  automake-1.15: error: cannot open <
> > >>  src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
> > >>  Makefile:1644: recipe for target 'Makefile.in' failed
> > >>  make: *** [Makefile.in] Error 1
> > >> 
> > >> 
> > >>  All in all I think it would make sense to remove this extra
> > Makefiles
> > >>  all together and stay with the one big Makefile build for 1.18. I
> > know
> > >>  the build times are frustrating and we might want to switch back
> > to a
> > >>  non aggregated Makefile to allow easier rebuilds of specific libs
> > >> only.
> > >> 
> > >>  Having a second, non working, build setup in tree for the release
> > is
> > >>  something I would like to avoid though.
> > >> 
> > >>  Comments?
> > >> >>>
> > >> >>> That's what I've been saying since they were introduced. Two build
> > >> >>> systems is a bad idea, we should just stay with single build until
> > we
> > >> >>> move to split.
> > >> >>
> > >> >> And it also make clear that nobody really care about per directory
> > >> >> build. Anyway. It has been now removed by commit
> > >> >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> > >> >
> > >> > actually that's wrong. i have used them.. BUT when i use them it goes
> > and
> > >> > rebuilds AGAIN in that dir and doesn't use my existing toplevel build.
> > >> that is
> > >> > SUPER annoying. i've also found them to be at least partially broken.
> > we
> > >> > discussed this long ago and no one wanted 2 build systems. almost
> > >> everyone
> > >> > except you wants per-directory build back again and there just is no
> > >> sane way
> > >> > to have both with a single file. the subdir builds needed to be the
> > ONLY
> > >> builds
> > >> > available.
> > >> >
> > >>
> > >> As long as distro people can still build everything from one command.
> > >>
> > >> If the subtree builds are just to save developer build time, why don't
> > >> you all just install ccache and be done with it, ccache significantly
> > >> reduces my efl rebuild times.
> > >
> > > We use it :) A basic incremental build is still very slow (touch an file
> > in
> > > eina to see...).
> > >
> > > The problem with the per-directory build was two-fold:
> > > - separate makefiles (totally unmanageable)
> >
> > Yes, only way around that would be to introduce our own pretool to
> > fill the Makefile.am with the proper list of files. The rest are
> > autotools limitation.
> >
> > > - it recompiled entirely each "module" (no incremental build after the
> > main
> > > build was run)
> >
> > Yes, that's due to the object naming convention used by autotools
> > which use the full relative path, but subsequent build would not
> > require a full rebuild. This is non fixable.
> >
> > > I know I broke the per directory build a few times, no one even said
> > > anything. That's how much it was used.
> >
> > Pretty much my point.
> >
> > Also I have run some benchmark, if we do go back to multiple Makefile
> > (If that was even doable), we will have a total build time when
> > nothing has changed significantly increased as our issue is in parsing
> > Makefile (9s on my laptop into parsing) and splitting Makefile will
> > result in duplicated boilerplate to parse. It also means that as long
> > 

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Jean-Philippe André]

On 4 August 2016 at 11:23, Cedric BAIL  wrote:

> On Mon, Aug 1, 2016 at 5:50 PM, Jean-Philippe André 
> wrote:
> > On 2 August 2016 at 09:30, Simon Lees  wrote:
> >> On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> >> > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL 
> >> said:
> >> >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen 
> >> wrote:
> >> >>> On 01/08/16 17:07, Stefan Schmidt wrote:
> >>  The extra Makefiles to allow building some libraries separately
> have
> >>  been broken for a while now. Nobody updated them when changes
> >> happened.
> >>  The normal problem when trying to have two build setups in one
> tree.
> >> 
> >>  I just gave it another go and ecore, edje, eio and elementary
> failed
> >> for
> >>  me.
> >> 
> >>  Many of them also fail from a tarball build because they include
> >>  Makefile_Eolian_Subbuild_Helper.am which never makes it into the
> >> tarball.
> >> 
> >>  cd ../../.. && /bin/sh
> >> /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> >>  automake-1.15 --gnu src/lib/ecore/Makefile
> >>  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is
> deprecated,
> >>  and its use is discouraged.
> >>  configure.ac:284: You should use the Autoconf-provided
> >> 'AC_PROG_MKDIR_P'
> >>  macro instead,
> >>  configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in
> your
> >>  Makefile.am files.
> >>  automake-1.15: error: cannot open <
> >>  src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
> >>  Makefile:1644: recipe for target 'Makefile.in' failed
> >>  make: *** [Makefile.in] Error 1
> >> 
> >> 
> >>  All in all I think it would make sense to remove this extra
> Makefiles
> >>  all together and stay with the one big Makefile build for 1.18. I
> know
> >>  the build times are frustrating and we might want to switch back
> to a
> >>  non aggregated Makefile to allow easier rebuilds of specific libs
> >> only.
> >> 
> >>  Having a second, non working, build setup in tree for the release
> is
> >>  something I would like to avoid though.
> >> 
> >>  Comments?
> >> >>>
> >> >>> That's what I've been saying since they were introduced. Two build
> >> >>> systems is a bad idea, we should just stay with single build until
> we
> >> >>> move to split.
> >> >>
> >> >> And it also make clear that nobody really care about per directory
> >> >> build. Anyway. It has been now removed by commit
> >> >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> >> >
> >> > actually that's wrong. i have used them.. BUT when i use them it goes
> and
> >> > rebuilds AGAIN in that dir and doesn't use my existing toplevel build.
> >> that is
> >> > SUPER annoying. i've also found them to be at least partially broken.
> we
> >> > discussed this long ago and no one wanted 2 build systems. almost
> >> everyone
> >> > except you wants per-directory build back again and there just is no
> >> sane way
> >> > to have both with a single file. the subdir builds needed to be the
> ONLY
> >> builds
> >> > available.
> >> >
> >>
> >> As long as distro people can still build everything from one command.
> >>
> >> If the subtree builds are just to save developer build time, why don't
> >> you all just install ccache and be done with it, ccache significantly
> >> reduces my efl rebuild times.
> >
> > We use it :) A basic incremental build is still very slow (touch an file
> in
> > eina to see...).
> >
> > The problem with the per-directory build was two-fold:
> > - separate makefiles (totally unmanageable)
>
> Yes, only way around that would be to introduce our own pretool to
> fill the Makefile.am with the proper list of files. The rest are
> autotools limitation.
>
> > - it recompiled entirely each "module" (no incremental build after the
> main
> > build was run)
>
> Yes, that's due to the object naming convention used by autotools
> which use the full relative path, but subsequent build would not
> require a full rebuild. This is non fixable.
>
> > I know I broke the per directory build a few times, no one even said
> > anything. That's how much it was used.
>
> Pretty much my point.
>
> Also I have run some benchmark, if we do go back to multiple Makefile
> (If that was even doable), we will have a total build time when
> nothing has changed significantly increased as our issue is in parsing
> Makefile (9s on my laptop into parsing) and splitting Makefile will
> result in duplicated boilerplate to parse. It also means that as long
> as we have that many files, modules and libraries, this parsing will
> be there and will likely still cost us that much. I have started
> looking at GNU make and I think there is room for serious improvement
> in their parsing code. Will see if I can manage something in the
> comming weeks.
>
> As for the reason why we 

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Cedric BAIL]

On Mon, Aug 1, 2016 at 5:50 PM, Jean-Philippe André  wrote:
> On 2 August 2016 at 09:30, Simon Lees  wrote:
>> On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
>> > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL 
>> said:
>> >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen 
>> wrote:
>> >>> On 01/08/16 17:07, Stefan Schmidt wrote:
>>  The extra Makefiles to allow building some libraries separately have
>>  been broken for a while now. Nobody updated them when changes
>> happened.
>>  The normal problem when trying to have two build setups in one tree.
>> 
>>  I just gave it another go and ecore, edje, eio and elementary failed
>> for
>>  me.
>> 
>>  Many of them also fail from a tarball build because they include
>>  Makefile_Eolian_Subbuild_Helper.am which never makes it into the
>> tarball.
>> 
>>  cd ../../.. && /bin/sh
>> /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
>>  automake-1.15 --gnu src/lib/ecore/Makefile
>>  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
>>  and its use is discouraged.
>>  configure.ac:284: You should use the Autoconf-provided
>> 'AC_PROG_MKDIR_P'
>>  macro instead,
>>  configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
>>  Makefile.am files.
>>  automake-1.15: error: cannot open <
>>  src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
>>  Makefile:1644: recipe for target 'Makefile.in' failed
>>  make: *** [Makefile.in] Error 1
>> 
>> 
>>  All in all I think it would make sense to remove this extra Makefiles
>>  all together and stay with the one big Makefile build for 1.18. I know
>>  the build times are frustrating and we might want to switch back to a
>>  non aggregated Makefile to allow easier rebuilds of specific libs
>> only.
>> 
>>  Having a second, non working, build setup in tree for the release is
>>  something I would like to avoid though.
>> 
>>  Comments?
>> >>>
>> >>> That's what I've been saying since they were introduced. Two build
>> >>> systems is a bad idea, we should just stay with single build until we
>> >>> move to split.
>> >>
>> >> And it also make clear that nobody really care about per directory
>> >> build. Anyway. It has been now removed by commit
>> >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
>> >
>> > actually that's wrong. i have used them.. BUT when i use them it goes and
>> > rebuilds AGAIN in that dir and doesn't use my existing toplevel build.
>> that is
>> > SUPER annoying. i've also found them to be at least partially broken. we
>> > discussed this long ago and no one wanted 2 build systems. almost
>> everyone
>> > except you wants per-directory build back again and there just is no
>> sane way
>> > to have both with a single file. the subdir builds needed to be the ONLY
>> builds
>> > available.
>> >
>>
>> As long as distro people can still build everything from one command.
>>
>> If the subtree builds are just to save developer build time, why don't
>> you all just install ccache and be done with it, ccache significantly
>> reduces my efl rebuild times.
>
> We use it :) A basic incremental build is still very slow (touch an file in
> eina to see...).
>
> The problem with the per-directory build was two-fold:
> - separate makefiles (totally unmanageable)

Yes, only way around that would be to introduce our own pretool to
fill the Makefile.am with the proper list of files. The rest are
autotools limitation.

> - it recompiled entirely each "module" (no incremental build after the main
> build was run)

Yes, that's due to the object naming convention used by autotools
which use the full relative path, but subsequent build would not
require a full rebuild. This is non fixable.

> I know I broke the per directory build a few times, no one even said
> anything. That's how much it was used.

Pretty much my point.

Also I have run some benchmark, if we do go back to multiple Makefile
(If that was even doable), we will have a total build time when
nothing has changed significantly increased as our issue is in parsing
Makefile (9s on my laptop into parsing) and splitting Makefile will
result in duplicated boilerplate to parse. It also means that as long
as we have that many files, modules and libraries, this parsing will
be there and will likely still cost us that much. I have started
looking at GNU make and I think there is room for serious improvement
in their parsing code. Will see if I can manage something in the
comming weeks.

As for the reason why we can't move to split Makefile.am, it's pretty
simple. It has to be done in one move due to how autotools handle sub
directories and dependencies. For anyone who has looked at our build
system, this is just litterally insane to do. We have to face it our
toolkit has grown big enough that any build system we use is 

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[The Rasterman]

On Tue, 2 Aug 2016 11:36:49 +1000 David Seikel  said:

> On Tue, 2 Aug 2016 09:50:13 +0900 Jean-Philippe André
>  wrote:
> 
> > On 2 August 2016 at 09:30, Simon Lees  wrote:
> > 
> > >
> > >
> > > On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> > > > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL
> > > > 
> > > said:
> > > >
> > > >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen
> > > >> 
> > > wrote:
> > > >>> On 01/08/16 17:07, Stefan Schmidt wrote:
> > >  Hello.
> > > 
> > >  The extra Makefiles to allow building some libraries
> > >  separately have been broken for a while now. Nobody updated
> > >  them when changes
> > > happened.
> > >  The normal problem when trying to have two build setups in one
> > >  tree.
> > > 
> > >  I just gave it another go and ecore, edje, eio and elementary
> > >  failed
> > > for
> > >  me.
> > > 
> > >  Many of them also fail from a tarball build because they
> > >  include Makefile_Eolian_Subbuild_Helper.am which never makes
> > >  it into the
> > > tarball.
> > > 
> > >  cd ../../.. && /bin/sh
> > > /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> > >  automake-1.15 --gnu src/lib/ecore/Makefile
> > >  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is
> > >  deprecated, and its use is discouraged.
> > >  configure.ac:284: You should use the Autoconf-provided
> > > 'AC_PROG_MKDIR_P'
> > >  macro instead,
> > >  configure.ac:284: and use '$(MKDIR_P)' instead of
> > >  '$(mkdir_p)'in your Makefile.am files.
> > >  automake-1.15: error: cannot open <
> > >  src/Makefile_Eolian_Subbuild_Helper.am: No such file or
> > >  directory Makefile:1644: recipe for target 'Makefile.in' failed
> > >  make: *** [Makefile.in] Error 1
> > > 
> > > 
> > >  All in all I think it would make sense to remove this extra
> > >  Makefiles all together and stay with the one big Makefile
> > >  build for 1.18. I know the build times are frustrating and we
> > >  might want to switch back to a non aggregated Makefile to
> > >  allow easier rebuilds of specific libs
> > > only.
> > > 
> > >  Having a second, non working, build setup in tree for the
> > >  release is something I would like to avoid though.
> > > 
> > >  Comments?
> > > >>>
> > > >>> That's what I've been saying since they were introduced. Two
> > > >>> build systems is a bad idea, we should just stay with single
> > > >>> build until we move to split.
> > > >>
> > > >> And it also make clear that nobody really care about per
> > > >> directory build. Anyway. It has been now removed by commit
> > > >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> > > >
> > > > actually that's wrong. i have used them.. BUT when i use them it
> > > > goes and rebuilds AGAIN in that dir and doesn't use my existing
> > > > toplevel build.
> > > that is
> > > > SUPER annoying. i've also found them to be at least partially
> > > > broken. we discussed this long ago and no one wanted 2 build
> > > > systems. almost
> > > everyone
> > > > except you wants per-directory build back again and there just is
> > > > no
> > > sane way
> > > > to have both with a single file. the subdir builds needed to be
> > > > the ONLY
> > > builds
> > > > available.
> > > >
> > >
> > > As long as distro people can still build everything from one
> > > command.
> > >
> > > If the subtree builds are just to save developer build time, why
> > > don't you all just install ccache and be done with it, ccache
> > > significantly reduces my efl rebuild times.
> > 
> > 
> > We use it :) A basic incremental build is still very slow (touch an
> > file in eina to see...).
> > 
> > The problem with the per-directory build was two-fold:
> > - separate makefiles (totally unmanageable)
> > - it recompiled entirely each "module" (no incremental build after
> > the main build was run)
> > 
> > I know I broke the per directory build a few times, no one even said
> > anything. That's how much it was used.
> 
> What I tend to do in big projects is to create per directory builds,
> then a top level script that calls the per directory builds if needed.
> That's the best of both worlds, without having two build systems.

that is what per dir makefiles do. subdir builds. you dont need scripts. our
isssue is we have a single makefile in src/ and thats it. (well another in
toplevel that recurses to src etc.).

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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[The Rasterman]

On Tue, 2 Aug 2016 10:00:16 +0930 Simon Lees  said:

> 
> 
> On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL  said:
> > 
> >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen  wrote:
> >>> On 01/08/16 17:07, Stefan Schmidt wrote:
>  Hello.
> 
>  The extra Makefiles to allow building some libraries separately have
>  been broken for a while now. Nobody updated them when changes happened.
>  The normal problem when trying to have two build setups in one tree.
> 
>  I just gave it another go and ecore, edje, eio and elementary failed for
>  me.
> 
>  Many of them also fail from a tarball build because they include
>  Makefile_Eolian_Subbuild_Helper.am which never makes it into the tarball.
> 
>  cd ../../.. && /bin/sh /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
>  automake-1.15 --gnu src/lib/ecore/Makefile
>  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
>  and its use is discouraged.
>  configure.ac:284: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
>  macro instead,
>  configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
>  Makefile.am files.
>  automake-1.15: error: cannot open <
>  src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
>  Makefile:1644: recipe for target 'Makefile.in' failed
>  make: *** [Makefile.in] Error 1
> 
> 
>  All in all I think it would make sense to remove this extra Makefiles
>  all together and stay with the one big Makefile build for 1.18. I know
>  the build times are frustrating and we might want to switch back to a
>  non aggregated Makefile to allow easier rebuilds of specific libs only.
> 
>  Having a second, non working, build setup in tree for the release is
>  something I would like to avoid though.
> 
>  Comments?
> >>>
> >>> That's what I've been saying since they were introduced. Two build
> >>> systems is a bad idea, we should just stay with single build until we
> >>> move to split.
> >>
> >> And it also make clear that nobody really care about per directory
> >> build. Anyway. It has been now removed by commit
> >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> > 
> > actually that's wrong. i have used them.. BUT when i use them it goes and
> > rebuilds AGAIN in that dir and doesn't use my existing toplevel build. that
> > is SUPER annoying. i've also found them to be at least partially broken. we
> > discussed this long ago and no one wanted 2 build systems. almost everyone
> > except you wants per-directory build back again and there just is no sane
> > way to have both with a single file. the subdir builds needed to be the
> > ONLY builds available.
> > 
> 
> As long as distro people can still build everything from one command.
> 
> If the subtree builds are just to save developer build time, why don't
> you all just install ccache and be done with it, ccache significantly
> reduces my efl rebuild times.

we do. i do. it STILL takes multiple minutes as opposed to under 5sec like it
used to.

> -- 
> 
> Simon Lees (Simotek)http://simotek.net
> 
> Emergency Update Team   keybase.io/simotek
> SUSE LinuxAdeliade Australia, UTC+9:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> 


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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[David Seikel]

On Tue, 2 Aug 2016 09:50:13 +0900 Jean-Philippe André
 wrote:

> On 2 August 2016 at 09:30, Simon Lees  wrote:
> 
> >
> >
> > On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> > > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL
> > > 
> > said:
> > >
> > >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen
> > >> 
> > wrote:
> > >>> On 01/08/16 17:07, Stefan Schmidt wrote:
> >  Hello.
> > 
> >  The extra Makefiles to allow building some libraries
> >  separately have been broken for a while now. Nobody updated
> >  them when changes
> > happened.
> >  The normal problem when trying to have two build setups in one
> >  tree.
> > 
> >  I just gave it another go and ecore, edje, eio and elementary
> >  failed
> > for
> >  me.
> > 
> >  Many of them also fail from a tarball build because they
> >  include Makefile_Eolian_Subbuild_Helper.am which never makes
> >  it into the
> > tarball.
> > 
> >  cd ../../.. && /bin/sh
> > /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> >  automake-1.15 --gnu src/lib/ecore/Makefile
> >  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is
> >  deprecated, and its use is discouraged.
> >  configure.ac:284: You should use the Autoconf-provided
> > 'AC_PROG_MKDIR_P'
> >  macro instead,
> >  configure.ac:284: and use '$(MKDIR_P)' instead of
> >  '$(mkdir_p)'in your Makefile.am files.
> >  automake-1.15: error: cannot open <
> >  src/Makefile_Eolian_Subbuild_Helper.am: No such file or
> >  directory Makefile:1644: recipe for target 'Makefile.in' failed
> >  make: *** [Makefile.in] Error 1
> > 
> > 
> >  All in all I think it would make sense to remove this extra
> >  Makefiles all together and stay with the one big Makefile
> >  build for 1.18. I know the build times are frustrating and we
> >  might want to switch back to a non aggregated Makefile to
> >  allow easier rebuilds of specific libs
> > only.
> > 
> >  Having a second, non working, build setup in tree for the
> >  release is something I would like to avoid though.
> > 
> >  Comments?
> > >>>
> > >>> That's what I've been saying since they were introduced. Two
> > >>> build systems is a bad idea, we should just stay with single
> > >>> build until we move to split.
> > >>
> > >> And it also make clear that nobody really care about per
> > >> directory build. Anyway. It has been now removed by commit
> > >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> > >
> > > actually that's wrong. i have used them.. BUT when i use them it
> > > goes and rebuilds AGAIN in that dir and doesn't use my existing
> > > toplevel build.
> > that is
> > > SUPER annoying. i've also found them to be at least partially
> > > broken. we discussed this long ago and no one wanted 2 build
> > > systems. almost
> > everyone
> > > except you wants per-directory build back again and there just is
> > > no
> > sane way
> > > to have both with a single file. the subdir builds needed to be
> > > the ONLY
> > builds
> > > available.
> > >
> >
> > As long as distro people can still build everything from one
> > command.
> >
> > If the subtree builds are just to save developer build time, why
> > don't you all just install ccache and be done with it, ccache
> > significantly reduces my efl rebuild times.
> 
> 
> We use it :) A basic incremental build is still very slow (touch an
> file in eina to see...).
> 
> The problem with the per-directory build was two-fold:
> - separate makefiles (totally unmanageable)
> - it recompiled entirely each "module" (no incremental build after
> the main build was run)
> 
> I know I broke the per directory build a few times, no one even said
> anything. That's how much it was used.

What I tend to do in big projects is to create per directory builds,
then a top level script that calls the per directory builds if needed.
That's the best of both worlds, without having two build systems.

-- 
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
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Jean-Philippe André]

On 2 August 2016 at 09:30, Simon Lees  wrote:

>
>
> On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL 
> said:
> >
> >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen 
> wrote:
> >>> On 01/08/16 17:07, Stefan Schmidt wrote:
>  Hello.
> 
>  The extra Makefiles to allow building some libraries separately have
>  been broken for a while now. Nobody updated them when changes
> happened.
>  The normal problem when trying to have two build setups in one tree.
> 
>  I just gave it another go and ecore, edje, eio and elementary failed
> for
>  me.
> 
>  Many of them also fail from a tarball build because they include
>  Makefile_Eolian_Subbuild_Helper.am which never makes it into the
> tarball.
> 
>  cd ../../.. && /bin/sh
> /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
>  automake-1.15 --gnu src/lib/ecore/Makefile
>  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
>  and its use is discouraged.
>  configure.ac:284: You should use the Autoconf-provided
> 'AC_PROG_MKDIR_P'
>  macro instead,
>  configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
>  Makefile.am files.
>  automake-1.15: error: cannot open <
>  src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
>  Makefile:1644: recipe for target 'Makefile.in' failed
>  make: *** [Makefile.in] Error 1
> 
> 
>  All in all I think it would make sense to remove this extra Makefiles
>  all together and stay with the one big Makefile build for 1.18. I know
>  the build times are frustrating and we might want to switch back to a
>  non aggregated Makefile to allow easier rebuilds of specific libs
> only.
> 
>  Having a second, non working, build setup in tree for the release is
>  something I would like to avoid though.
> 
>  Comments?
> >>>
> >>> That's what I've been saying since they were introduced. Two build
> >>> systems is a bad idea, we should just stay with single build until we
> >>> move to split.
> >>
> >> And it also make clear that nobody really care about per directory
> >> build. Anyway. It has been now removed by commit
> >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> >
> > actually that's wrong. i have used them.. BUT when i use them it goes and
> > rebuilds AGAIN in that dir and doesn't use my existing toplevel build.
> that is
> > SUPER annoying. i've also found them to be at least partially broken. we
> > discussed this long ago and no one wanted 2 build systems. almost
> everyone
> > except you wants per-directory build back again and there just is no
> sane way
> > to have both with a single file. the subdir builds needed to be the ONLY
> builds
> > available.
> >
>
> As long as distro people can still build everything from one command.
>
> If the subtree builds are just to save developer build time, why don't
> you all just install ccache and be done with it, ccache significantly
> reduces my efl rebuild times.


We use it :) A basic incremental build is still very slow (touch an file in
eina to see...).

The problem with the per-directory build was two-fold:
- separate makefiles (totally unmanageable)
- it recompiled entirely each "module" (no incremental build after the main
build was run)

I know I broke the per directory build a few times, no one even said
anything. That's how much it was used.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Simon Lees]

On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL  said:
> 
>> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen  wrote:
>>> On 01/08/16 17:07, Stefan Schmidt wrote:
 Hello.

 The extra Makefiles to allow building some libraries separately have
 been broken for a while now. Nobody updated them when changes happened.
 The normal problem when trying to have two build setups in one tree.

 I just gave it another go and ecore, edje, eio and elementary failed for
 me.

 Many of them also fail from a tarball build because they include
 Makefile_Eolian_Subbuild_Helper.am which never makes it into the tarball.

 cd ../../.. && /bin/sh /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
 automake-1.15 --gnu src/lib/ecore/Makefile
 configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
 and its use is discouraged.
 configure.ac:284: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
 macro instead,
 configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
 Makefile.am files.
 automake-1.15: error: cannot open <
 src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
 Makefile:1644: recipe for target 'Makefile.in' failed
 make: *** [Makefile.in] Error 1


 All in all I think it would make sense to remove this extra Makefiles
 all together and stay with the one big Makefile build for 1.18. I know
 the build times are frustrating and we might want to switch back to a
 non aggregated Makefile to allow easier rebuilds of specific libs only.

 Having a second, non working, build setup in tree for the release is
 something I would like to avoid though.

 Comments?
>>>
>>> That's what I've been saying since they were introduced. Two build
>>> systems is a bad idea, we should just stay with single build until we
>>> move to split.
>>
>> And it also make clear that nobody really care about per directory
>> build. Anyway. It has been now removed by commit
>> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> 
> actually that's wrong. i have used them.. BUT when i use them it goes and
> rebuilds AGAIN in that dir and doesn't use my existing toplevel build. that is
> SUPER annoying. i've also found them to be at least partially broken. we
> discussed this long ago and no one wanted 2 build systems. almost everyone
> except you wants per-directory build back again and there just is no sane way
> to have both with a single file. the subdir builds needed to be the ONLY 
> builds
> available.
> 

As long as distro people can still build everything from one command.

If the subtree builds are just to save developer build time, why don't
you all just install ccache and be done with it, ccache significantly
reduces my efl rebuild times.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[The Rasterman]

On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL  said:

> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen  wrote:
> > On 01/08/16 17:07, Stefan Schmidt wrote:
> >> Hello.
> >>
> >> The extra Makefiles to allow building some libraries separately have
> >> been broken for a while now. Nobody updated them when changes happened.
> >> The normal problem when trying to have two build setups in one tree.
> >>
> >> I just gave it another go and ecore, edje, eio and elementary failed for
> >> me.
> >>
> >> Many of them also fail from a tarball build because they include
> >> Makefile_Eolian_Subbuild_Helper.am which never makes it into the tarball.
> >>
> >> cd ../../.. && /bin/sh /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> >> automake-1.15 --gnu src/lib/ecore/Makefile
> >> configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
> >> and its use is discouraged.
> >> configure.ac:284: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
> >> macro instead,
> >> configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
> >> Makefile.am files.
> >> automake-1.15: error: cannot open <
> >> src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
> >> Makefile:1644: recipe for target 'Makefile.in' failed
> >> make: *** [Makefile.in] Error 1
> >>
> >>
> >> All in all I think it would make sense to remove this extra Makefiles
> >> all together and stay with the one big Makefile build for 1.18. I know
> >> the build times are frustrating and we might want to switch back to a
> >> non aggregated Makefile to allow easier rebuilds of specific libs only.
> >>
> >> Having a second, non working, build setup in tree for the release is
> >> something I would like to avoid though.
> >>
> >> Comments?
> >
> > That's what I've been saying since they were introduced. Two build
> > systems is a bad idea, we should just stay with single build until we
> > move to split.
> 
> And it also make clear that nobody really care about per directory
> build. Anyway. It has been now removed by commit
> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.

actually that's wrong. i have used them.. BUT when i use them it goes and
rebuilds AGAIN in that dir and doesn't use my existing toplevel build. that is
SUPER annoying. i've also found them to be at least partially broken. we
discussed this long ago and no one wanted 2 build systems. almost everyone
except you wants per-directory build back again and there just is no sane way
to have both with a single file. the subdir builds needed to be the ONLY builds
available.

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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Cedric BAIL]

On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen  wrote:
> On 01/08/16 17:07, Stefan Schmidt wrote:
>> Hello.
>>
>> The extra Makefiles to allow building some libraries separately have
>> been broken for a while now. Nobody updated them when changes happened.
>> The normal problem when trying to have two build setups in one tree.
>>
>> I just gave it another go and ecore, edje, eio and elementary failed for me.
>>
>> Many of them also fail from a tarball build because they include
>> Makefile_Eolian_Subbuild_Helper.am which never makes it into the tarball.
>>
>> cd ../../.. && /bin/sh /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
>> automake-1.15 --gnu src/lib/ecore/Makefile
>> configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
>> and its use is discouraged.
>> configure.ac:284: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
>> macro instead,
>> configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
>> Makefile.am files.
>> automake-1.15: error: cannot open <
>> src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
>> Makefile:1644: recipe for target 'Makefile.in' failed
>> make: *** [Makefile.in] Error 1
>>
>>
>> All in all I think it would make sense to remove this extra Makefiles
>> all together and stay with the one big Makefile build for 1.18. I know
>> the build times are frustrating and we might want to switch back to a
>> non aggregated Makefile to allow easier rebuilds of specific libs only.
>>
>> Having a second, non working, build setup in tree for the release is
>> something I would like to avoid though.
>>
>> Comments?
>
> That's what I've been saying since they were introduced. Two build
> systems is a bad idea, we should just stay with single build until we
> move to split.

And it also make clear that nobody really care about per directory
build. Anyway. It has been now removed by commit
dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
-- 
Cedric BAIL

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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[Tom Hacohen]

On 01/08/16 17:07, Stefan Schmidt wrote:
> Hello.
>
> The extra Makefiles to allow building some libraries separately have
> been broken for a while now. Nobody updated them when changes happened.
> The normal problem when trying to have two build setups in one tree.
>
> I just gave it another go and ecore, edje, eio and elementary failed for me.
>
> Many of them also fail from a tarball build because they include
> Makefile_Eolian_Subbuild_Helper.am which never makes it into the tarball.
>
> cd ../../.. && /bin/sh /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> automake-1.15 --gnu src/lib/ecore/Makefile
> configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is deprecated,
> and its use is discouraged.
> configure.ac:284: You should use the Autoconf-provided 'AC_PROG_MKDIR_P'
> macro instead,
> configure.ac:284: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your
> Makefile.am files.
> automake-1.15: error: cannot open <
> src/Makefile_Eolian_Subbuild_Helper.am: No such file or directory
> Makefile:1644: recipe for target 'Makefile.in' failed
> make: *** [Makefile.in] Error 1
>
>
> All in all I think it would make sense to remove this extra Makefiles
> all together and stay with the one big Makefile build for 1.18. I know
> the build times are frustrating and we might want to switch back to a
> non aggregated Makefile to allow easier rebuilds of specific libs only.
>
> Having a second, non working, build setup in tree for the release is
> something I would like to avoid though.
>
> Comments?

That's what I've been saying since they were introduced. Two build 
systems is a bad idea, we should just stay with single build until we 
move to split.

--
Tom.


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