Re: [PATCH] Remove data/Makefile.am.

[Akim Demaille]

Le 15 nov. 08 à 18:56, Joel E. Denny a écrit :

Hi Joel,

> While debugging, writing test cases, and documenting, I often do  
> things
> like:
>
>  % touch lalr.c && make CFLAGS="-O0 -g" lalr.o && make # helps gdb  
> for lalr.c
>  % make testsuite && ./testsuite -v 32
>  % make bison.info && info --file=./bison.info
>
> However, these are all broken now.  In the worst cases, incorrect  
> implicit
> rules take over and appear to succeed but miss dependencies.  I  
> think it's
> going to be annoying to have to maintain dummy makefiles that handle  
> every
> target a developer might think to make especially given that bad  
> implicit
> rules might take over when we forget one.

But what exactly does not work?  You can still do the same thing:

touch src/lalr.c && make CFLAGS="-O0 -g" src/lalr.o && make src/bison

make tests/testsuite && tests/testsuite -v 32

or simply make check TESTSUITEFLAGS='-v 32'

make doc/bison.info && info --file=doc/bison.info

The only difference is that you no longer run cd beforehand.  It's the  
same as using make -C, without -C.


> What's the real motivation behind this change?  You said that  
> recursive
> make is too slow.  However, after running "git clean -dfx && ./ 
> bootstrap
> && ./configure && time make" for each of branch-2.4.1, master, and  
> commit
> 06344 (that's master before you started this change), I find that  
> they all
> consistently take about 40s of real time on my system.  Is there  
> another
> use case?

My principal motivation is to use distcc as much as I can.  With  
frequent rebasing and changes, switching from one branch to another,  
sequential builds were slowing down my process.   I have also learned  
to prefer single Makefiles in that the dependencies are much more  
correct.

All the potential for concurrency is not achieved yet, because I have  
yet to convert lib/.