On Wed, 24 Dec 2003 15:00:03 +0100,
Bram Moolenaar <Bram@...
> Mark Waggoner wrote:
> > I needed to modify this to be:
> > perlcppflags=`$vi_cv_path_perl -Mlib=$srcdir -MExtUtils::Embed \
> > -e 'ccflags;perl_inc;print"\n"' | sed -e 's/-fno[^ ]*//'`
> Why doesn't Perl add a newline after the text it writes to stdout?
> Anyway, that's how it is.
It's a *good* thing that Perl doesn't add a newline. The output of the
subs ccflags(), perl_inc(), ldopts(), &c. was designed to be "glued"
into a cc command line, such as:
cc -o prog prog.c `perl -MExtUtils::Embed -e ccflags -e ldopts`
Naturally, you wouldn't want newlines in the middle of your cc command.
> > This is likely also hitting the problem, though it didn't prevent
> > building:
> > PERL_LIBS=`cd $srcdir; $vi_cv_path_perl -MExtUtils::Embed -e
'ldopts' | \
> > sed -e '/Warning/d' -e '/Note (probably harmless)/d' \
> > -e 's/-bE:perl.exp//' -e 's/-lc //'`
> This text *does* end in a newline. Thus Perl works different here.
> Don't know why...
I can't resist: Because the programmer told it to!
Perl, unlike Python, doesn't automatically add a newline for each print
statement (unless invoked with -l [that's dash-el]). Looking at the
source for the cc "glue" subs in ExtUtils::Embed v 1.2501, the only sub
with a newline appended to it's output is ldopts().
Why? I'm not sure, but I note that all of the examples in the man pages
perlembed and ExtUtils::Embed have ldopts() being called last (or at the
end) on the cc lines. Maybe ldopts() works best if called last and the
newline is there to enforce that ordering - just speculation on my part.
Jonathan D Johnston
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!