On 7/31/13 7:59 PM, Johannes Schlüter wrote:
On Wed, 2013-07-31 at 19:31 +0000, Christopher Jones wrote:
Commit:    017145bc57e604153f2a2400dd6e73a397f52f96 Author:    Christopher Jones 
<s...@php.net>         Wed, 31 Jul 2013 12:31:50 -0700 Parents:
4ed18d5955ad7ac0172f6eec87735fefcd113270 Branches:  PHP-5.5 master


Log: Allow 'make distclean' to clean up the 'generated' phar.inc

This seems to be the wrong "fix" for the actual issue.

-$(builddir)/phar/phar.inc: $(srcdir)/phar/phar.inc +$(builddir)/phar/phar.inc: 
$(srcdir)/phar/phar.inc.in -@test -d $(builddir)/phar || mkdir
$(builddir)/phar -      -@test -f $(builddir)/phar/phar.inc || cp 
$(srcdir)/phar/phar.inc $(builddir)/phar/phar.inc +   -@test -f
$(builddir)/phar/phar.inc || cp $(srcdir)/phar/phar.inc.in 

This rule copies the file from the source to the buildir for out of tree builds 

$(builddir)/phar.php: $(srcdir)/build_precommand.php $(srcdir)/phar/*.inc 
$(srcdir)/phar/*.php $(SAPI_CLI_PATH) -@echo "Generating phar.php"

... where it is then used by this rule, so phar.php can include it easily or 
something. (a quick scan over the file didn't tell me why that .inc is
different from the others ...)

If sourcedir == builddir nothing should happen in the first step.

If I read the Makefile correctly (mind the "$(srcdir)/phar/" argument to the 
"phar.php pack" call) the .in file will be added to the generated
phar, too.

I don't now which exact problem is meant to be solved with this change but copying files 
around for "no reason" seems weird. Maybe the copy from
srcdir to builddir can be avoided at all?


When srcdir != builddir then a 'make distclean' needs to remove the
installed copy of the file.  However a unilateral rm on the file would
affect the source copy in the case when srcdir == builddir, since the
paths & names are identical.  My patch solved this by making sure the
rm never affected the base source file.  All phar tests passed, BTW.

What the copy is for, only the (nonexistent) phar maintainer can tell.
(this is why I did the change in a separate commit, so it can be
reverted etc).

Your followup fix looks better, though it pushes some phar
logic-awareness into Makefile.global.  (Unless we can add a
'distcleanphar' target in phar/Makefile.frag and add that target as a
dependency to Makefile.global's 'distclean'. This could depend how the
Makefile gets constructed and if the target is always present - I
might leave this icing to a phar person).


christopher.jo...@oracle.com  http://twitter.com/ghrd
Free PHP & Oracle book:

PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to