Re: Option ansi2knr mishandles sources in different directories

[Alexandre Duret-Lutz]

>>> "Kevin" == Kevin Ryde <address@hidden> writes:

 Kevin> This is also my PR/370 covered I guess.

Ah... thanks.  I had never noticed this PR :(

 Kevin> I notice the _.c is produced in the subdirectory.  In
 Kevin> GMP we've got a case where we'd like to take sources
 Kevin> from a directory which also has its own build of the
 Kevin> respective files, with the two builds using a couple of
 Kevin> different -D defines (just using the INCLUDES variable).

This seems close to PR/374.  Basically the complain is that the
.c -> _.c rule should honor per-target CFLAGS.  It seems you
are just trying to emulate this using two Makefiles defining
different INCLUDES.

 Kevin> I wonder if the old way of having the _.c in the current
 Kevin> directory could be retained.

If so we'd need to separate rules for bar.o and bar_.o, as you
suggest in PR/370.  I guess it would also be a good thing for
PR/374.

 Kevin> I also notice in this change that if the subdirectory
 Kevin> doesn't have its own Makefile.am then the _.c isn't
 Kevin> removed by a clean or distclean.

Another bug is that dependencies for desansified subdirectory
sources are output in the wrong files (`.deps/bar.Po' instead of
`.deps/bar_.Po').


Something that would be nice is to rewrite the ansi2knr
supporting code as a language.  Just like Yacc and Lex are
handled as languages that produce another source that get
compiled.  I think this would make the code more malleable and
comprehensible (I find the current ansi2knr support really hard
to follow).  However I'm not sure how that would work if we
don't keep _.c and .c in the same directory: the next language,
C, needs to consider only one source (bar$U.c) in this scheme.

Sigh.  Let's sleep.
-- 
Alexandre Duret-Lutz