# from Jan Dubois
# on Thursday 15 January 2009 18:58:
>On Thu, 15 Jan 2009, David Golden wrote:
>>Sadly, even my proposed "for (1 .. 20) " type loop around rmtree were
>>insufficient to avoid the problem.
>You could create an additional single temp directory, redefine
>CORE::GLOBAL::unlink() to rename() files into this directory (using
>unique names) before unlink()ing them, and then remove this special
> temp directory at the very end. If you can't remove that directory
> even after a few retries, just leave it behind and don't signal a
> failure.
Maybe.
But I just found myself thinking about skipping tests and then realized
that we're talking about compat.t and presumably the Compat.pm call to
delete_filetree(), or perhaps something running `Build realclean` or so
on, right?
>>>> Couldn't remove 'blib': Directory not empty
>>>> dmake: Error code 169, while making 'realclean'
(And btw, we're probably 4 or even 6 "processes" deep at this point.)
>>>> t\compat.t ... Failed test 'make realclean ran without error'
Which means code designed to be used only in a fallback case is
potentially causing the installation to fail when the user would
probably (especially on win32) have a happier experience by simply
never using said code.
So, I'm inclined to skip that entire test file (or at least large
portions of it) on win32 and recommend that compat mode not be used
there.
Is that a suitable solution?
For those with reservations about not testing the process of using
`make` to run `Build` (when part of the whole idea was to be able to
remove `make` from the picture), please consider the set of win32 users
who are fortunate enough to have a correctly configured client (so as
to not need the compat mode) and yet are being inconvenienced due to a
subtle and intermittent failure while testing code they will never use.
It seems like a fair trade-off to leave mis-configured users to an
unknown fate rather than crying FAIL at well-configured users about a
moot bug.
If the intermittent test error does not yield to a simple solution,
skipping it completely in this case seems reasonable from my point of
view. Somehow enabling it via environment variable
(AUTOMATED_TESTING?) might, of course, still be desirable.
David, is it indeed only an issue with compat.t?
Now, *authors* on win32 should certainly have a tested Compat.pm with
regard to generating Makefile.PL, but that points more toward splitting
compat.t than against deprecating usage of Makefile.PL.
--Eric
--
"Everything should be made as simple as possible, but no simpler."
--Albert Einstein
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
