search

Perl5-Alien / Alien-Base

Base classes for Alien:: modules (deprecated, see Alien-Build)
Other
35 stars 19 forks source link

Intermittent test failure on Strawberry Perl / MSWin32 #183

Closed plicease closed 7 years ago

plicease commented 7 years ago

https://gist.github.com/plicease/c7612b0ebd930d14c180af0972325bd2 http://www.cpantesters.org/cpan/report/94bb5b4f-6bfc-1014-a5c0-96d0fda9e585 http://www.cpantesters.org/cpan/report/388bdef9-00f6-1015-812d-9a1decc4b8ad

wbraswell commented 7 years ago

Yes this is affecting AppVeyor builds: https://ci.appveyor.com/project/rurban/rperl/build/1.0.8#L6036

plicease commented 7 years ago

I think 0.037_01 may fix this. I can push a prod version if we can verify.

plicease commented 7 years ago

I was able to reproduce this and have added additional fixes as 0.037_02. Awaiting feedback.

plicease commented 7 years ago

Weird combination of factors led to this bug:

  1. PkgConfig.pm now supports static cflags, which is seldom used in practice atm (but may be used more widely with the rise pkgconf). This bug tends to manifest itself on windows because Strawberry uses PkgConfig.pm as the system pkg-config, and because it happens to have a .pc file that expresses the problem. Other platforms tend to use either pkg-config which does not support static cflags, or pkgconf old enough not to support static cflags. (feature was only recently added to pkgconf).
  2. Logic flip in cflags and cflags_static methods (fixed in 0.037_01)
  3. Additional bugs in t/yy-system_installed.t revealed when trying to reproduce this (hopefully fixed in 0.037_02).

t/yy-system_installed.t is not a very good test! Part of what it is testing is actually tested (better) in t/alien_base.t now. Part of what it is testing is not. Although I believe I have this test at least reliably not failing, it depends on random factors and frequently tests nothing! A better test should be written for the aspect that does not get tested by t/alien_base.t, and t/yy-system_installed.t should be removed in the longer term.

Compounding this is that I am not currently receiving detailed cpantesters results for either 0.037_01 or 0.037_02. I am able to see the matrix log view. There are some failures in 0.037_01 which I think may be fixed in 0.037_02, but no way of telling with out either 1) detailed log for 0.037_01 or 2) no failures in the log matrix for 0.037_02 (the latter may take a day or two to see).

wbraswell commented 7 years ago

@plicease

Well the latest AppVeyor builds of RPerl are passing for both me and rurban, but I don't know how to tell if it is due to your new changes?

https://ci.appveyor.com/project/rurban/rperl

https://ci.appveyor.com/project/wbraswell/rperl

plicease commented 7 years ago

@wbraswell since those are using 0.036 I'd say probably not.

wbraswell commented 7 years ago

Okay well if they are passing now with the old version then that's good too I guess? Sorry but I'm not sure how else to help on this particular issue...

plicease commented 7 years ago

Releasing production as 0.038. I believe this is fixed, but we can reopen if we see it again.