[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: toolchain/45669: lib-src Makefile:136: *** recipe commences before first target. Stop
The following reply was made to PR pkg/45669; it has been noted by GNATS.
From: Mike Riechers <mlr%rse.com@localhost>
Subject: Re: toolchain/45669: lib-src Makefile:136: *** recipe commences before
first target. Stop
Date: Tue, 29 Nov 2011 14:18:00 -0500
On Tuesday 29 November 2011 4:30:06 am Martin Husemann wrote:
> The following reply was made to PR toolchain/45669; it has been noted by
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Subject: Re: toolchain/45669: lib-src Makefile:136: *** recipe commences
> before first target. Stop Date: Tue, 29 Nov 2011 10:25:03 +0100
> On Tue, Nov 29, 2011 at 01:25:00AM +0000, mlr%rse.com@localhost wrote:
> > Dunno. Better of:
> > Change the behavior of the new gcc cpp to honour the \<eol> sequence.
> Since the output is equivalent for C, it makes no sense to blame the C
> preprocessor for this output.
> So IMHO better do:
> > Change the sed sequence in emacs-20.7/configure to snuff all \<eol>:
> But maybe you can get away with "cpp -x assembler-with-cpp" or cpp
> -std=... for now?
Thanks for addressing this issue.
My gut says you are right. But a couple of points.
1. I've racked my brain for some simple combination of sed/tr to rid the
file of all \<eol>'s, safely, under all conditions of input, but I can't.
Seems silly that such a simple thing can't be done short of writing a
short C program to to it. Actually, does one exist?
2. I'm curious to know how and why the preprocessor changed, and what the
"cpp -x assembler-with-cpp", etc, will do. The change appears to be
undocumented, since info says that " 3. Continued lines are merged into
one long line." as part of "1.2 Initial processing", without qualification,
as far as I can tell.
But I can get away with any option that works, for now.
Main Index |
Thread Index |