la 2013-01-08 01:23 Michael G Schwern via RT skribis:
Show quoted text
:-)
Show quoted text>> 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 mysteriously 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 (equivalently, as far as make is concerned) to
>> 'signature:' without the space, since statements can't have ':' in their
>> name.
> First thing you should know is I'm not a make expert, but I have come to
> learn what's portable and what isn't. I've also come to learn that
> nothing is simple.
>
> Unfortunately some make variants on VMS need that space.
The Perl Makefile.SH produces rules without this space, so it can't be so
important.
Show quoted text> Just about
> every target in MakeMaker was normalized to be "target :". Every make
> variant MakeMaker supports (BSD, Solaris, GNU, MMK, nmake, dmake) works
> fine with that space, so I'd need so see some solid evidence otherwise.
> In fact, the GNU make docs explicitly use "target :".
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...)
Show quoted text> Personally, I find it absurd that there might be a syntactic difference
> between "target:" and "target :". You may wish to consider dropping
> that distinction or bringing it in line with what everything else does.
>
> Reading the makepp docs
> <
http://makepp.sourceforge.net/2.1/makepp_statements.html#signature_name> "A
> statement is any line beginning with a word which does not have a : in
> it." A simple, and much safer, fix would be to make an exception for
> whitespace between the word and the colon. "A statement is any line
> beginning with a word which does not have a : following it."
Thanks for spotting that inconsistency! Actually this lead to lots of
headaches with statements like 'perl { ... A::B ... }' disappearing
mysteriously. They were being seen as a rule (which was of course useless and
getting silently ignored like any unneeded rule). There were other headaches,
which made me align this with what I wrote above for gmake.
Show quoted text> I'd say you've found a bug/incompatibility in makepp's make extension
> syntax. I'd rather see it fixed in makepp than play whack-a-mole with
> whatever future collisions we have between make targets and makepp
> keywords. I'd patch the signature target to support existing versions
> of makepp, but that might play havoc with MMK.
If it really does matter, I suggest this work-around:
ifdef MAKEPP_VERSION
signature:
else
signature :
endif
Show quoted text>> What completely baffles me is FALSE. You repeatedly use it in 2 ways, in an
>> echo action, where the return code is ignored via initial '-', so that's
>> completely useless.
> This illustrates the difference between "-cmd" and "-cmd; false".
>
> echo_ignore_false :
> @-echo "Foo"; false;
>
> $ make echo_ignore_false
> Foo
> make: [echo_ignore_false] Error 1 (ignored)
Ok, fine, you get a warning... Anyway, this one only struck me as being
useless, it works fine in makepp so I don't care.
Show quoted text>> 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...
> That target is supposed to fail and stop. Then you manually re-run
> make. This feature predates me, but I presume it is there because
> MakeMaker does not run Makefile.PL with any arguments and so probably
> got it wrong.
If it was originally wrong, it should be rebuilt in any make (though other
makes ignore most dependencies, except explicit ones after the colon). And if
it's rebuilt, why not use it immediately? Failing looks nasty and makes the
user uncertain he's on the right track.
Show quoted text> If makepp is remembering that the build of the Makefile failed between
> runs, this is an interesting feature but it is different from how every
> other make we support does it.
That is probably so, because makepp is the only make that promises
reliability. It achieves that by remembering everything about the targets it
produces, and rebuilding them if any kind of dependency (including the
architecture it built on, the command string and the executables it calls)
changes. Therefore it will never include a file it knows to be broken, unless
you force it to via --dont-build. And that's an option for bad tricks, not
for a normal build.
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
