[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Option ansi2knr mishandles sources in different directories

From: Alexandre Duret-Lutz
Subject: Re: Option ansi2knr mishandles sources in different directories
Date: Fri, 22 Nov 2002 00:35:55 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu)

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

 Kevin> I also notice in this change that if the subdirectory
 Kevin> doesn't have its own 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]