'make distclean' defect #14108
Comments
From @jkeenanWith this ticket I bring into RT the discussion that began on list starting at: In this post I summarize that discussion, present current documentation relevant to the problem and describe one policy question which needs to be resolved before a solution can be implemented. I. Discussion of Problem Steve Hay initiated the discussion in the context of working on core on Win32: ##### "distclean certainly used to work at some time in the (recent?) past." Subsequent posts confirmed that this problem is *not* limited to Win32 and has existed for some time. Some have suggested that 'make distclean' be made an alias for 'git clean -dfx', but others have pointed out that you cannot and should not assume that one is always working within a git checkout. 'make distclean' presumably DTRT for Perl 5 core developers before we switched to git as our revision control system. It should not have been allowed to fall into disrepair. [My editorial comments: There is no guarantee that git will be the last revision control system Perl will ever use, so we shouldn't tie ourselves too closely to it. TMTOWTDI encourages this and prudence recommends this. 'git clean -dfx' may DTRT for *many* Perl 5 core developers *much* of the time, the mere fact that we are having this discussion indicates that it does not DTRT for all core developers all of the time.] II. Documentation of Current Functionality A. 'make distclean' 'make distclean' is documented in INSTALL under the heading "Starting all over again": ##### B. 'git clean -dfx' From 'man git-clean' for Git 1.9.l: ##### Normally, only files unknown to Git are removed, but if the -x option is specified, ignored files are also removed. This can, for example, be useful to remove all build products. Here is what I believe to be the most relevant parts of the documentation of the three options: ##### -f: If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given -f, -n or -i. -x: This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build. C. Attachments Attached are three files derived from a perl built on Linux x86_64 in blead. 'git clean -dfx' was run before a fetch from origin and rebase, then perl was configured only with '-des -Dusedevel', then perl was built and tested. * Output from 'git clean -dfx' after from-scratch build: git.clean.dfx.txt * Output from 'make distclean' after from-scratch build: make.distclean.txt * Output from 'git clean -dfx' after 'make distclean' has been run: activated.after.make.distclean.git.clean.dfx.txt Examination of the latter suggests that almost all of the files and directories which 'make distclean' is failing to remove and which we would presumably expect it to remove are found under 'lib/'. III. Policy Issues A. Scope of Defect Are we in agreement that, given an otherwise pristine working directory, 'make distclean' should remove the same directories and files as 'git clean -dfx'? In other words, after running 'make distclean' should a file like attachment activated.after.make.distclean.git.clean.dfx.txt be empty? B. Scope of 'make distclean' relative to 'git clean -dfx' 'make distclean' does not rely on the revision control system for the list of files to be removed. It relies on MANIFEST, Makefile and its predecessors, etc. As such, it is not documented to remove any files the user may have in the working directory which are not under revision control or are not build artifacts. Suppose I had in my working directory a little shell script to configure a DEBUGGING build. ##### #/bin/sh 'make distclean' would presumably *not* remove that shell script as it is neither under revision control nor a build artifact. 'git clean', however, treats the working directory primarily as a git checkout and -- particularly with '-dfx' -- aims to get that checkout back to a pristine state from git's point of view. git's point of view is not necessarily perl's or the developer's point of view. 'git clean -dfx' would nuke that shell script wrapping around Configure. Once we have corrected the defect in III.A. above, are we happy with the fact that 'make distclean' and 'git clean -dfx' have somewhat different objectives and hence achieve different results? IV. Summary Once we've resolved III.A. and III.B., patches welcome! Thank you very much. -- |
From @jkeenanRemoving lib/Attribute/ |
From @jkeenanWould remove .config/ |
From @jkeenanSummary of my perl5 (revision 5 version 21 subversion 5) configuration: Characteristics of this binary (from libperl): |
From [Unknown Contact. See original ticket]Summary of my perl5 (revision 5 version 21 subversion 5) configuration: Characteristics of this binary (from libperl): |
From @craigberrydistclean also fails to clean up entirely with v5.20.1-3-g479259f and v5.18.3-RC1-2-g77d4f3e distclean leaves some things behind but all of So I think both John and Steve are right. I think what John saw a |
From @craigberryThe problem could be readily reduced to: $ ./miniperl -Ilib make_ext.pl --target=all Exporter MAKE="make" and observing that lib/Exporter.pm was still there after it was Fixed in 9fa5aa9. Side note: "make clean" is even more seriously broken -- it removes |
|
@jkeenan - Status changed from 'new' to 'open' |
From @jkeenanOn Sun Sep 21 18:40:52 2014, craig.a.berry@gmail.com wrote:
I'm amazed that Craig solved this so quickly. Craig's patch assumes -- correctly, IMO -- that 'make distclean' and 'git clean -dfx' have slightly different objectives. Going back to the example I provided in section III.B above, I: * Placed in my working directory a small shell script, mydebugconfigure.sh, wrapping around Configure. This DWIMs for me. Thank you very much. |
From @steve-m-hayOn Sun Sep 21 18:40:52 2014, craig.a.berry@gmail.com wrote:
Excellent! Thanks for the fix. Closing ticket now. |
|
@steve-m-hay - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#122820 (status was 'resolved')
Searchable as RT122820$
The text was updated successfully, but these errors were encountered: