develooper Front page | perl.perl5.porters | Postings from January 2012

Re: Detecting duplicate extension directories

Thread Previous | Thread Next
Nicholas Clark
January 27, 2012 08:38
Re: Detecting duplicate extension directories
Message ID:
On Fri, Jan 27, 2012 at 11:18:35AM -0500, David Golden wrote:
> > I don't agree. We support building outside of git repositories, because
> >
> > a: we distribute tarballs
> > b: we build on platforms that don't support git
> I agree.  I'll quote your original message back to you:
> > This isn't a problem when building from a distribution tarball or
> > other clean checkout, but it is causing "fun" (ie strange noisy catastrophic
> > build failures) when anyone runs git pull on a build checkout, and then
> > runs disclean before starting again.
> > We can't assume that
> >
> > a: git is present to do our work for us
> >
> > b: that we can get it to delete all the build files, without also deleting
> >   user owned files. distclean is careful to only delete the things that we
> >   know we built.
> Per your identification of the problem, we can assume (a).  Regarding
> (b), I don't think we have to automate a solution, only tell the user
> that they're doing it wrong.
> > I've just presented a *working solution* to a current problem.
> > Even if we adopt your plan, it will do as an interim solution until your
> > plan delivers a solution.
> I'm suggesting an alternative approach I think is better.  Just
> because I suggest an alternative doesn't mean you couldn't/shouldn't
> go forward with the change you've proposed.


I thought you were meaning generally about distclean, not just this case.

In this case, I think it's impossible (in the general case) to be able to
automatically decide the right thing to do.

Given that

a: Configure assumes that any directory under ext/ dist/ or cpan/ is an
   extension. The structure in them is variable enough that it's not really
   possible to work out which is "live", and which is build detritus
b: The approach Configure takes (still) supports placing any unpacked
   CPAN distribution below ext/ (etc) and trying to build it. We don't
   parse MANIFEST to find the list of extensions. I think that it's useful
   to continue being able to build anything put there
   (I've used it in the past to build Devel::NYTProf to profile blead's
    build and test scripts. Particularly to get parallel testing working)
c: We can't know if any file is actually something the user cares about
Given (a) and (b), the only solution as far as Configure is concerned is
to remove the "wrong" directory, to leave only the "right" directory.
The problem is that we can't rm -rf dist/$wrong because it might contain
user files. eg given this:

$ ls */Hash-Util-FieldHash/

Changes         FieldHash.o     Makefile.PL     pm_to_blib    FieldHash.xs    blib            t
FieldHash.c     Makefile        lib

we can't know whether it's safe to delete dist/Hash-Util-FieldHash/
so as to be able to delete dist/Hash-Util-FieldHash/

but if we don't delete dist/Hash-Util-FieldHash/ Configure will list
it as both a non-XS and an XS extension. In turn Makefile.SH will create a
Makefile that tries to build it as a non-XS extension. In turn, that fails
without any obvious diagnostic as to *why*. The error will probably be about
not finding ExtUtils::ParseXS or somesuch, but the underlying cause is that
the XS part of the toolchain isn't bootstrapped yet.

That's why I think think that it's not possible to solve the general problem
of automatically cleaning up for this scenario.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About