From occitan@esperanto.org

Hi,

I've picked up my attempts to compile perl (5.16.2) with http​://makepp.sf.net,
now that makepp is more gmake compatible than ever. These are the 3 changes
it took​:

The 1st stumbling block is perly.[ch]. Since there are rules, makepp will run
them. Since the targets are write protected, makepp will remove them first.
But the rules are a lie, they succeed, but don't produce the files, making
further compilations fail :-( Wrap them like this in Makefile.SH​:1141​: to
hide them from makepp​:

ifndef MAKEPP_VERSION
perly.c​: perly.y
  -@​sh -c true

perly.h​: perly.y
  -@​sh -c true
endif

The same is true in x2p/Makefile.SH​:143​: for a2p.c.

Last year makepp was aligned with gmake, in that statements have a higher
parsing priority than rules. (This made statements like 'perl { ... A​::B ...
}' no longer look like a rule and myteriously disappear, so this change was
rather useful.) But now the following snippet found in many generated
makefiles is seen as a statement (makepp is strongly signature based, rather
than relying only on timestamps), trying to specify an unknown signature
method named '​:'​:
# --- MakeMaker signature section​:
signature :
  cpansign -s

This comes from cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm​:1445​: which
should be changed (equvalently, as far as make is concerned) to 'signature​:',
since statements can't have '​:' in their name.

What completely baffles me is FALSE. You repeatedly use it in 2 places, in an
echo action, where the return code is ignored via initial '-', so that's
completely useless. And in the rules that remake FIRST_MAKEFILE, which you
thus force to fail. I have no idea why this works with make, but of course
makepp will not reload a Makefile that failed to build. I worked around that
with 'export FALSE=​:' but that can't be the solution...

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From @iabyn

On Sun, Jan 06, 2013 at 08​:47​:31AM -0800, Daniel Pfeiffer wrote​:

I've picked up my attempts to compile perl (5.16.2) with http​://makepp.sf.net,
now that makepp is more gmake compatible than ever. These are the 3 changes
it took​:

The 1st stumbling block is perly.[ch]. Since there are rules, makepp will run
them. Since the targets are write protected, makepp will remove them first.
But the rules are a lie, they succeed, but don't produce the files, making
further compilations fail :-( Wrap them like this in Makefile.SH​:1141​: to
hide them from makepp​:

ifndef MAKEPP_VERSION
perly.c​: perly.y
-@​sh -c true

perly.h​: perly.y
-@​sh -c true
endif

The same is true in x2p/Makefile.SH​:143​: for a2p.c.

I think it would be easier to just remove those two rules; they are no
longer needed AFAIKT.

[ second issue ]

This comes from cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm​:1445​:

Any issues with MakeMaker should be reported at the CPAN bug tracker,
http​://rt.cpan.org .

--
I don't want to achieve immortality through my work...
I want to achieve it through not dying.
  -- Woody Allen

The RT System itself - Status changed from 'new' to 'open'

From occitan@esperanto.org

la 2013-01-07 16​:22 Dave Mitchell via RT skribis​:

This comes from cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm​:1445​:
Any issues with MakeMaker should be reported at the CPAN bug tracker,
http​://rt.cpan.org .

I opened

https://rt.cpan.org/Ticket/Display.html?id=82548

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From @craigberry

On Sun, Jan 6, 2013 at 10​:47 AM, Daniel Pfeiffer
<perlbug-followup@​perl.org> wrote​:

Last year makepp was aligned with gmake, in that statements have a higher
parsing priority than rules. (This made statements like 'perl { ... A​::B ...
}' no longer look like a rule and myteriously disappear, so this change was
rather useful.) But now the following snippet found in many generated
makefiles is seen as a statement (makepp is strongly signature based, rather
than relying only on timestamps), trying to specify an unknown signature
method named '​:'​:
# --- MakeMaker signature section​:
signature :
cpansign -s

To me this looks unambiguously like a target with no dependencies.

This comes from cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm​:1445​: which
should be changed (equvalently, as far as make is concerned) to 'signature​:',
since statements can't have '​:' in their name.

Statements perhaps not, but targets can. At least on Windows and VMS
they can. The space before the colon is intentional and essential.
Lots of things would break if it were removed.

From occitan@esperanto.org

la 2013-01-08 02​:00 Craig A. Berry skribis​:

On Sun, Jan 6, 2013 at 10​:47 AM, Daniel Pfeiffer
<perlbug-followup@​perl.org> wrote​:

Last year makepp was aligned with gmake, in that statements have a higher
parsing priority than rules. (This made statements like 'perl { ... A​::B ...
}' no longer look like a rule and myteriously disappear, so this change was
rather useful.) But now the following snippet found in many generated
makefiles is seen as a statement (makepp is strongly signature based, rather
than relying only on timestamps), trying to specify an unknown signature
method named '​:'​:
# --- MakeMaker signature section​:
signature :
cpansign -s
To me this looks unambiguously like a target with no dependencies.

In gmake this is a target with no dependencies​:

include​:

while this is a statement with an argument of '​:'​:

include :

Makepp follows the same logic, only that it has many more statements than
gmake. (And you can even define your own as a Perl function...)

This comes from cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm​:1445​: which
should be changed (equvalently, as far as make is concerned) to 'signature​:',
since statements can't have '​:' in their name.
Statements perhaps not, but targets can. At least on Windows and VMS
they can. The space before the colon is intentional and essential.
Lots of things would break if it were removed.

Leaving out the space is valid rule syntax. What would break by removing it,
please? The Makefile.SH generated one for building Perl has rules without
this space and it doesn't break anything. The space is of course also valid,
but in case of a target called the same as a statement in some versions of
make, it is not always valid...

Try to make your makefiles as general as you can! That way Perl can be built
with the Perl make, which is makepp. And other packages that use MakeMaker
likewise.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From @craigberry

On Tue, Jan 8, 2013 at 3​:11 PM, Daniel Pfeiffer <occitan@​t-online.de> wrote​:

la 2013-01-08 02​:00 Craig A. Berry skribis​:

On Sun, Jan 6, 2013 at 10​:47 AM, Daniel Pfeiffer
<perlbug-followup@​perl.org> wrote​:

Last year makepp was aligned with gmake, in that statements have a higher
parsing priority than rules. (This made statements like 'perl { ... A​::B
...
}' no longer look like a rule and myteriously disappear, so this change
was
rather useful.) But now the following snippet found in many generated
makefiles is seen as a statement (makepp is strongly signature based,
rather
than relying only on timestamps), trying to specify an unknown signature
method named '​:'​:
# --- MakeMaker signature section​:
signature :
cpansign -s

To me this looks unambiguously like a target with no dependencies.

In gmake this is a target with no dependencies​:

include​:

while this is a statement with an argument of '​:'​:

include :

Makepp follows the same logic, only that it has many more statements than
gmake. (And you can even define your own as a Perl function...)

Hmm. So in

foo :

foo is a statement with a colon as an argument if and only if foo
happens to be a known statement, but is a target with no dependencies
if there is no such statement as foo? And whether foo is a statement
or not depends on whether there is such a statement pre-defined in the
utility and/or added by the user? Sounds like a recipe for disaster.

This comes from cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm​:1445​:
which
should be changed (equvalently, as far as make is concerned) to
'signature​:',
since statements can't have '​:' in their name.

Statements perhaps not, but targets can. At least on Windows and VMS
they can. The space before the colon is intentional and essential.
Lots of things would break if it were removed.

Leaving out the space is valid rule syntax.

With most make and make-like utilities, yes, but not all. Here is one
where it's a syntax error​:

$ cat Makefile
foo​:
  @​ write sys$output "hello"
$ mmk
%MMK-F-PARSERR, error parsing description line foo​:
-MMK-I-ERRLOC, at line number 1 in file DISK8​:[CBERRY.TEST]MAKEFILE.;2
-LIB-F-SYNTAXERR, string syntax error detected by LIB$TPARSE

Add the space and everything is peachy​:

$ mmk
hello

What would break by removing it, please?

All building of Perl extensions on VMS, which is something I maintain,
thus my interest in not having it broken :-).

The Makefile.SH generated one for building Perl has rules
without this space and it doesn't break anything.

The top-level Makefile is not used on all platforms. The
MakeMaker-generated files are.

The space is of course
also valid, but in case of a target called the same as a statement in some
versions of make, it is not always valid...

Try to make your makefiles as general as you can!

That is exactly what MakeMaker is trying to do already, but we've now
encountered a collision over what counts as general. I think I
understand your problem now but I'm not sure what to suggest. Is
there any way to undeclare statements in a Makefile, so that MakeMaker
could reserve "signature" for its own purposes and not have it
accidentally turned into a statement?

From Eirik-Berg.Hanssen@allverden.no

On Tue, Jan 8, 2013 at 11​:13 PM, Craig A. Berry <craig.a.berry@​gmail.com>wrote​:

Hmm. So in

foo :

foo is a statement with a colon as an argument if and only if foo
happens to be a known statement, but is a target with no dependencies
if there is no such statement as foo? And whether foo is a statement
or not depends on whether there is such a statement pre-defined in the
utility and/or added by the user? Sounds like a recipe for disaster.

  Yeah, that sounds bad. Hmm ... make syntax really is annoying in the
first place ...

  Would something like <<THIS prevent interpretation as statement
"signature"?

nul=

${nul} signature :

THIS

  A quick test seems to indicate it does. Yay! :)

  But is it portable? :-\

Eirik

From occitan@esperanto.org

la 2013-01-08 23​:13 Craig A. Berry skribis​:

On Tue, Jan 8, 2013 at 3​:11 PM, Daniel Pfeiffer <occitan@​t-online.de> wrote​:

In gmake this is a target with no dependencies​: include​: while this is a
statement with an argument of '​:'​: include : Makepp follows the same logic,
only that it has many more statements than gmake. (And you can even define
your own as a Perl function...)
Hmm. So in

foo :

foo is a statement with a colon as an argument if and only if foo
happens to be a known statement, but is a target with no dependencies
if there is no such statement as foo? And whether foo is a statement
or not depends on whether there is such a statement pre-defined in the
utility and/or added by the user? Sounds like a recipe for disaster.

Another example that came to mind, in gmake "export​:" and "export a​:=1" also
fall into the two different categories. Problem comes with Shell type
unquoted strings. I don't like make-syntax at all, but long ago I started
with a completely new make.pl, with Perl syntax, and I didn't see that as ever
gaining wide acceptance...

Leaving out the space is valid rule syntax.
With most make and make-like utilities, yes, but not all. Here is one
where it's a syntax error​:

$ cat Makefile
foo​:
@​ write sys$output "hello"
$ mmk
%MMK-F-PARSERR, error parsing description line foo​:
-MMK-I-ERRLOC, at line number 1 in file DISK8​:[CBERRY.TEST]MAKEFILE.;2
-LIB-F-SYNTAXERR, string syntax error detected by LIB$TPARSE

Add the space and everything is peachy​:

$ mmk
hello

Not compatibly with original make, but hey, now there's two of us, going in
different directions. Obviously makpp being gmake compatible while
drastically improving on its shortcomings is squaring the circle...

Try to make your makefiles as general as you can!
That is exactly what MakeMaker is trying to do already, but we've now
encountered a collision over what counts as general. I think I
understand your problem now but I'm not sure what to suggest. Is
there any way to undeclare statements in a Makefile, so that MakeMaker
could reserve "signature" for its own purposes and not have it
accidentally turned into a statement?

ifdef MAKEPP_VERSION
perl { undef *s_signature }
endif

signature :
  cpansign -s

But as we learnt in this discussion, ifdef isn't portable either, so that's no
good.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From occitan@esperanto.org

la 2013-01-09 00​:03 Eirik Berg Hanssen skribis​:

On Tue, Jan 8, 2013 at 11​:13 PM, Craig A. Berry <craig.a.berry@​gmail.com
<mailto​:craig.a.berry@​gmail.com>> wrote​:

Hmm\.  So in

foo :

foo is a statement with a colon as an argument if and only if foo
happens to be a known statement\, but is a target with no dependencies
if there is no such statement as foo?  And whether foo is a statement
or not depends on whether there is such a statement pre\-defined in the
utility and/or added by the user?  Sounds like a recipe for disaster\.

Yeah, that sounds bad. Hmm ... make syntax really is annoying in the
first place ...

Would something like <<THIS prevent interpretation as statement "signature"?

nul=

${nul} signature :

THIS

A quick test seems to indicate it does. Yay! :)

But is it portable? :-\

As I answered to [rt.cpan.org #82548] MM_Any breaks makepp, trivial to fix​:

An alternative, up to you to decide which youprefer, would be

signature=signature

${signature} :
  cpansign -s

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From occitan@esperanto.org

la 2013-01-07 16​:22 Dave Mitchell via RT skribis​:

On Sun, Jan 06, 2013 at 08​:47​:31AM -0800, Daniel Pfeiffer wrote​:

I've picked up my attempts to compile perl (5.16.2) with http​://makepp.sf.net,
now that makepp is more gmake compatible than ever. These are the 3 changes
it took​:

The 1st stumbling block is perly.[ch]. Since there are rules, makepp will run
them. Since the targets are write protected, makepp will remove them first.
But the rules are a lie, they succeed, but don't produce the files, making
further compilations fail :-( Wrap them like this in Makefile.SH​:1141​: to
hide them from makepp​:

ifndef MAKEPP_VERSION
perly.c​: perly.y
-@​sh -c true

perly.h​: perly.y
-@​sh -c true
endif

The same is true in x2p/Makefile.SH​:143​: for a2p.c.
I think it would be easier to just remove those two rules; they are no
longer needed AFAIKT.

I just checked and saw that 5.17.8 is out. But nothing happened about this.
When can it be expected?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From @doughera88

On Tue, 29 Jan 2013, Daniel Pfeiffer wrote​:

la 2013-01-07 16​:22 Dave Mitchell via RT skribis​:

On Sun, Jan 06, 2013 at 08​:47​:31AM -0800, Daniel Pfeiffer wrote​:

I've picked up my attempts to compile perl (5.16.2) with
http​://makepp.sf.net,
now that makepp is more gmake compatible than ever. These are the 3
changes
it took​:

The 1st stumbling block is perly.[ch]. Since there are rules, makepp will
run
them. Since the targets are write protected, makepp will remove them
first.
But the rules are a lie, they succeed, but don't produce the files, making
further compilations fail :-( Wrap them like this in Makefile.SH​:1141​: to
hide them from makepp​:

ifndef MAKEPP_VERSION
perly.c​: perly.y
-@​sh -c true

perly.h​: perly.y
-@​sh -c true
endif

The same is true in x2p/Makefile.SH​:143​: for a2p.c.
I think it would be easier to just remove those two rules; they are no
longer needed AFAIKT.

I just checked and saw that 5.17.8 is out. But nothing happened about this.
When can it be expected?

Here's the problem​: Without those "rules", traditional make will
erroneously try to run yacc if perly.c or perly.h is out of date, which
can easily happen if they are patched, particularly if the tool that
generates the patches sorts the patches in alphabetical order (as git diff
does, for example).

To demonstrate the problem​:

1. Unpack perl-5.17.8.tar.gz from cpan.
2. cd perl-5.17.8
3. Apply this patch​:

--- Makefile.SH.orig	2013-01-29 16:56:48.213936545 -0500
+++ Makefile.SH	2013-01-29 16:57:28.534092377 -0500
@@ -1145,15 +1145,6 @@
 regen_perly regen-perly:
 	perl regen_perly.pl
 
-# We don't want to regenerate perly.c and perly.h, but they might
-# appear out-of-date after a patch is applied or a new distribution is
-# made.
-perly.c: perly.y
-	-@sh -c true
-
-perly.h: perly.y
-	-@sh -c true
-
 SYM  = globvar.sym perlio.sym
 
 SYMH = perlvars.h intrpvar.h

  $ make
  [ . . . lines omitted . . . ]
  `sh cflags "optimize='-O2'" gv.o` gv.c
  CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall
  `sh cflags "optimize='-O2'" toke.o` toke.c
  CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall
  yacc perly.y
  make​: yacc​: Command not found
  make​: *** [perly.c] Error 127

(Of course if you have yacc installed you get a different error, but you
get the idea.)

I don't know the best way around the problem. It's probably to hide
perly.y somewhere that regen_perly.pl will find it but that make won't.
Until that's fixed, however, I think we'd better not break the usual case
of running ordinary 'make'.

--
  Andy Dougherty doughera@​lafayette.edu