Front page | perl.perl5.porters |
Postings from January 2012
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.
OK.
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/
dist/Hash-Util-FieldHash/:
Valuable.pm
ext/Hash-Util-FieldHash/:
Changes FieldHash.o Makefile.PL pm_to_blib
FieldHash.bs FieldHash.xs blib t
FieldHash.c Makefile lib
we can't know whether it's safe to delete dist/Hash-Util-FieldHash/Valuable.pm
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