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

[Joel E. Denny]

On Sat, 15 Nov 2008, Akim Demaille wrote:

> Le 15 nov. 08 à 14:01, Samuel Tardieu a écrit :
> 
> > Are you sure this is a good idea? As a general rule, I don't find it
> > practical to use "local.mk" instead of "Makefile.am". In my own
> > projects, I like being able to "make -C data" when I work on stuff
> > which is local to this directory, instead of having to do "make
> > data/something" which forces me to give an explicit list of targets.
> 
> I agree, I have the same concern, and I wish that Automake would provide me
> with both (generate a full Makefile with complete dependencies, maximally
> concurrency builds and so forth, *and* a local Makefile that would just bounce
> to the main one).
> 
> But in the case of Bison there are no directories that play such a role.
> Besides, it is easy to write dummy Makefiles that bounce to local targets
> you'd like to have.

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.

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?

Thanks.