I have forwarded this whole thread to Rob Janes, the current maintainer of CPANPLUS.
Sorry first. Compress::Bzip2 won't generate reports when $Config{"cc"}
is missing. So I assume there is some way to disable reports for
missing $Config{"cc"}, and as a XS module author you should employ that.
I was wrong. Digging into CPANPLUS I cannot found any mechanism for
that. Maybe I was wrong here again.
Personally I think whether $Config{"cc"} is available for XS modules
should be checked at CPANPLUS, and a N/A report should be sent if
$Config{"cc"} is not available. As a module author you can check if
$Config{"cc"} is available and make some decision (although I don't know
what decision). Maybe some graceful failure on that?
And Randy, I don't agree with you. Perl may be distributed as
binaries (and that is mostly the case). Often the building environment
is not the same as the running environment. For the OS characteristics
like $Config{"flock"}, it's reasonable to assume that it is reliable.
But for $Config{"cc"}, assuming its existence is no doubt a mistake.
And the test reporter are only reporting my environment, honestly.
Whether you want to deal with that gracefully is really out of my
concern. There are lots of FAIL in this list. There is still another
option: ignoring it.
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Marcus Holland-Moritz <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Wed, 15 Jun 2005 17:19:16 +0200
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
Hi,
On 2005-06-15, at 20:59:27 +0800, [EMAIL PROTECTED] wrote:
> [MSG] [Wed Jun 15 20:58:58 2005] Checking if your kit is complete...
> Looks good
> Building with feature 'ieeefp'
> Building with feature 'threads'
> Finding dependencies...
> Writing Makefile for Convert::Binary::C
>
> [ERROR] [Wed Jun 15 20:59:10 2005] MAKE failed: No such file or directory cp
> lib/Convert/Binary/C/Cached.pm blib\lib\Convert\Binary\C\Cached.pm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> cp lib/Convert/Binary/C.pm blib\lib\Convert\Binary\C.pm
> C:\Perl\bin\perl.exe "-Iblib\arch" "-Iblib\lib" ctlib/arch.pl
> ctlib/arch.h
> C:\Perl\bin\perl.exe C:\Perl\lib\ExtUtils\xsubpp -typemap
> C:\Perl\lib\ExtUtils\typemap -typemap typemap C.xs > C.xsc &&
> C:\Perl\bin\perl.exe -MExtUtils::Command -e mv C.xsc C.c
> cl -c -I. -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
> -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
> -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1
> -DVERSION=\"0.59\" -DXS_VERSION=\"0.59\" "-IC:\Perl\lib\CORE"
> -DUCPP_CONFIG -DUCPP_REENTRANT -DUTIL_HAVE_CONFIG_H -DCBC_HAVE_IEEE_FP
> -DNDEBUG -DCBC_THREAD_SAFE C.c
>
> Microsoft (R) Program Maintenance Utility Version 1.50
> Copyright (c) Microsoft Corp 1988-94. All rights reserved.
>
> 'cl' 不是內部或外部命令、
> 可執行的程式或批次檔。
^^^^^^^^^^^^^^^^^^^^^^^^^
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'
> Stop.
I'm quite sure there's a problem with your setup.
I know that Convert::Binary::C builds fine on Windows/cl, because
I've tested it myself, and because there are a lot of Windows/cl
test reports that PASS.
I've also seen the same error for other XS modules reported by your
smoke setup. Have you tried building an XS module by hand with this
setup?
So, could you either make sure that this smoke is set up correctly,
or just stop this smoke, because it seems to be generating wrong
reports.
Thanks,
Marcus
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: imacat <[EMAIL PROTECTED]>
To: Marcus Holland-Moritz <[EMAIL PROTECTED]>
Date: Thu, 16 Jun 2005 00:30:25 +0800
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
On Wed, 15 Jun 2005 17:19:16 +0200
Marcus Holland-Moritz <[EMAIL PROTECTED]> wrote:
> > cl -c -I. -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
> > -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
> > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1
> > -DVERSION=\"0.59\" -DXS_VERSION=\"0.59\" "-IC:\Perl\lib\CORE"
> > -DUCPP_CONFIG -DUCPP_REENTRANT -DUTIL_HAVE_CONFIG_H -DCBC_HAVE_IEEE_FP
> > -DNDEBUG -DCBC_THREAD_SAFE C.c
> >
> > Microsoft (R) Program Maintenance Utility Version 1.50
> > Copyright (c) Microsoft Corp 1988-94. All rights reserved.
> >
> > 'cl' 不是內部或外部命令、
> > 可執行的程式或批次檔。
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'
> > Stop.
>
> I'm quite sure there's a problem with your setup.
>
> I know that Convert::Binary::C builds fine on Windows/cl, because
> I've tested it myself, and because there are a lot of Windows/cl
> test reports that PASS.
>
> I've also seen the same error for other XS modules reported by your
> smoke setup. Have you tried building an XS module by hand with this
> setup?
>
> So, could you either make sure that this smoke is set up correctly,
> or just stop this smoke, because it seems to be generating wrong
> reports.
Hi,
The same. I'm quite sure there's a problem with your setup. I
won't check whether that smoke is set up correctly, nor stop that smoke.
It is not generating wrong reports.
That Chinese error message means "'cl' is neither an internal
command, external command, executable nor batch file." It means I don't
have the 'cl' C compiler. Most XS modules won't generate error reports
when 'cl' is missing. Check their modules for how to prevent error
reports on that case, before accusing my reports are wrong.
If you ask the meaning of that Chinese message first, or any
information on my report, I'd be glad to help. But when you arbitrarily
accuse that my reports are wrong, and even ask me to stop sending the
so-called "wrong reports", it'll be hard for me to pay respect to you.
That's too much. I'm providing my CPU, my harddisk, my bandwidth, my
time to help testing tens of new packages everyday. I believe I don't
deserve it.
--
Best regards,
imacat ^_*' <[EMAIL PROTECTED]>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Marcus Holland-Moritz <[EMAIL PROTECTED]>
To: imacat <[EMAIL PROTECTED]>
Date: Wed, 15 Jun 2005 19:55:02 +0200
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
Hi imacat,
First of all, I'm sorry if my first mail sounded offensive to you.
That really wasn't my intention.
On 2005-06-16, at 00:30:25 +0800, imacat wrote:
> Hi,
>
> The same. I'm quite sure there's a problem with your setup. I
> won't check whether that smoke is set up correctly, nor stop that smoke.
> It is not generating wrong reports.
>
> That Chinese error message means "'cl' is neither an internal
> command, external command, executable nor batch file." It means I don't
> have the 'cl' C compiler.
Ok, that makes sense.
> Most XS modules won't generate error reports when 'cl' is missing.
I'm not sure this is true. I just grep'd through my cpan-testers
directory for your reports, and there's quite a couple of XS modules
that fail with exactly the same 'cl is missing' error.
Please feel free to point me at some pure XS module that don't fail.
Most XS modules that check whether or not a compiler is available are
hybrid modules. They are still able to build and work, probably with
limited functionality, even without a compiler. I do myself own such
a module, and its Makefile.PL has appropriate checks.
However, Convert::Binary::C and lots (most) other XS modules require
that a C compiler is installed. If one tries to build those modules
without a compiler, they get an error from the operating system that
no compiler is installed, which is "good enough" for those modules.
But that doesn't mean they don't work. They just lack a prerequisite.
On most platforms, you have access to a compiler. On Windows, if you
don't have a compiler, you're most probably using ActiveState perl
and PPM, so you don't need to have a compiler.
> Check their modules for how to prevent error
> reports on that case, before accusing my reports are wrong.
Obviously, I could check for a compiler in my Makefile.PL. However,
I do check for so many other things that this file has already grown
to over 700 lines. I wonder if it's worth making this file even more
complex just to add a check that doesn't serve any purpose other than
to make test reports from systems without a compiler pass. (Besides,
the best I could get is NA, since the module still wouldn't work.)
And I still think that your test reports are "wrong" in the way that
a) the source of the failure it isn't obvious by looking at the report,
unless you're fluent in Chinese, and
b) rarely anyone ever looks at the detailed reports; they browse CPAN
search, they see failure on Windows, they assume the modules doesn't
work on Windows.
And b) just isn't true. It works. All you need is a compiler, or if you
don't have one, the PPM distribution from ActiveState.
> If you ask the meaning of that Chinese message first, or any
> information on my report, I'd be glad to help. But when you arbitrarily
> accuse that my reports are wrong, and even ask me to stop sending the
> so-called "wrong reports", it'll be hard for me to pay respect to you.
> That's too much. I'm providing my CPU, my harddisk, my bandwidth, my
> time to help testing tens of new packages everyday. I believe I don't
> deserve it.
Don't get me wrong, I really appreciate your effort. And your linux
and cygwin setups are great. But the Windows/cl setup is generating
"FAIL" reports for many XS modules that would work just fine if a
compiler was installed. Those reports are not "wrong" in the sense
that they contain invalid information. But they suggest the wrong
thing to CPAN visitors.
So, that's my view on the situation.
Now, what would be the possible solutions? The ones I can think of are:
1) Don't change anything. This would mean a lot of XS modules would
get FAIL reports.
2) Have every CPAN author that owns XS modules check for a working
compiler.
3) You install a compiler on your machine, or you stop that specific
smoke. There are already a couple of people who have set up
Windows smoke boxes. And your other smoke setups are fine, so
this suggestion really isn't meant offensive.
Again, sorry if my first mail sounded a little harsh.
Best wishes,
Marcus
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Robert Rothenberg <[EMAIL PROTECTED]>
To: Marcus Holland-Moritz <[EMAIL PROTECTED]>
Date: Wed, 15 Jun 2005 20:59:14 +0100
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
Marcus,
> ... And I still think that your test reports are "wrong" in the way that
Test reports are not wrong if they accurately reflect what happens what
happens on the system. If there's no C compiler, and the tests fail,
then the report should show that.
A "problem" is that CPANPLUS is not yet sophisticated to recognize this
and do what it should, which is to not send a report. Or maybe
CPANPLUS, MakeMaker, etc. should recognize that the module requires a C
compiler and refuse to try and build it in the first place.
Or maybe the CPAN::WWW::Testers software can be updated to differentiate
failure reports due to missing compilers from other kinds of failures.
> a) the source of the failure it isn't obvious by looking at the report,
> unless you're fluent in Chinese, and
I can't read Chinese and could figure it out:
> > Microsoft (R) Program Maintenance Utility Version 1.50
> > Copyright (c) Microsoft Corp 1988-94. All rights reserved.
> >
> > 'cl' 不是內部或外部命令、
> > 可執行的程式或批次檔。
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return
code '0x1'
> > Stop.
and so what if it's in Chinese?
Maybe in the future the testing system will be sophisticated enough to
read meta-data and know to send test reports in multiple languages (the
author's and tester's).
> b) rarely anyone ever looks at the detailed reports; they browse CPAN
> search, they see failure on Windows, they assume the modules doesn't
> work on Windows.
Anyone who uses test reports to determine whether a module works or not
on their platform would look at the failure reports.
CPAN "visitors" should have a minimum technical ability to decipher
failure reports. If they are evaluating a module that may suit their
needs, presumably they would not superficially ignore it just because it
failed in some test reports.
There are many types of failure reports, and often for reasons beyond
the author's control.
Accept that failures (and even strange unknown and na reports) happen.
> 3) You install a compiler on your machine, or you stop that specific
> smoke. There are already a couple of people who have set up
> Windows smoke boxes. And your other smoke setups are fine, so
> this suggestion really isn't meant offensive.
So "visitors" would see that your module works on some Windows
platforms, and not be too worried about failures.
We need platforms without compilers to run tests, so that code which
recognizes that there is no compiler and acts accordingly can be tested!
I agree 100% with imacat here:
> I'm providing my CPU, my harddisk, my bandwidth, my
> time to help testing tens of new packages everyday.
This is a volunteer effort. People are trying to contribute to the
community, and they get little back for it. If they get criticised for
trying to help out, then they'll stop helping out.
If you don't like what's happening, do something contructive like submit
patches to ExtUtils::MakeMaker and Module::Build, CPANPLUS,
Test::Reporter, CPAN::YACSmoke or CPAN::WWW::Testers to minimize failure
reports like this one.
Regards,
Rob
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Randy Kobes <[EMAIL PROTECTED]>
To: Marcus Holland-Moritz <[EMAIL PROTECTED]>
Date: Wed, 15 Jun 2005 16:24:33 -0500 (CDT)
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
On Wed, 15 Jun 2005, Marcus Holland-Moritz wrote:
[ ... ]
> Obviously, I could check for a compiler in my Makefile.PL.
> However, I do check for so many other things that this
> file has already grown to over 700 lines. I wonder if it's
> worth making this file even more complex just to add a
> check that doesn't serve any purpose other than to make
> test reports from systems without a compiler pass.
> (Besides, the best I could get is NA, since the module
> still wouldn't work.)
Perhaps one thing that could be done in cases like imacat is
to change the tester's Perl Config.pm to accurately
reflect what's really available on the system; by what's reported:
=====================================================================
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
[ ... ]
Compiler:
cc='cl',
[ ... ]
=====================================================================
a module author can reasonably expect that a working C
compiler (cl) is present. As Marcus says, adding checks to
see if what Config.pm says is really true or not seems
extreme.
--
best regards,
randy kobes
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Marcus Holland-Moritz <[EMAIL PROTECTED]>
To: Robert Rothenberg via CPAN <[EMAIL PROTECTED]>
Date: Thu, 16 Jun 2005 00:11:07 +0200
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
Hi Robert,
Hi imacat,
I can only apologize again for the tone in my first email.
On 2005-06-15, at 20:59:14 +0100, Robert Rothenberg wrote:
> > ... And I still think that your test reports are "wrong" in the way that
>
> Test reports are not wrong if they accurately reflect what happens what
> happens on the system.
Sure, and I really, really appreciate the CPAN testers facility.
It helped me more than once to spot real problems with my modules.
> If there's no C compiler, and the tests fail, then the report should show
> that.
^^^^^^^^^^^^^^^^^^
Yes, but there isn't a single test executed.
> A "problem" is that CPANPLUS is not yet sophisticated to recognize this
> and do what it should, which is to not send a report.
Agreed.
> Or maybe CPANPLUS, MakeMaker, etc. should recognize that the module requires
> a C compiler and refuse to try and build it in the first place.
For registered modules, CPAN(PLUS) could use the DLSIP code.
Or there could be some information in the META.yml.
> Or maybe the CPAN::WWW::Testers software can be updated to differentiate
> failure reports due to missing compilers from other kinds of failures.
>
> > a) the source of the failure it isn't obvious by looking at the report,
> > unless you're fluent in Chinese, and
>
> I can't read Chinese and could figure it out:
To me, it looked like it was running 'cl' and failing.
But I couldn't figure out the reason why it was failing.
I was -- wrongly -- assuming the presence of a compiler.
> > > Microsoft (R) Program Maintenance Utility Version 1.50
> > > Copyright (c) Microsoft Corp 1988-94. All rights reserved.
> > >
> > > 'cl' 不是內部或外部命令、
> > > 可執行的程式或批次檔。
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > > NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return
> code '0x1'
> > > Stop.
>
> and so what if it's in Chinese?
>
> Maybe in the future the testing system will be sophisticated enough to
> read meta-data and know to send test reports in multiple languages (the
> author's and tester's).
Maybe. But the Chinese error above seems to be generated by
the OS rather than by the testing system.
> > b) rarely anyone ever looks at the detailed reports; they browse CPAN
> > search, they see failure on Windows, they assume the modules doesn't
> > work on Windows.
>
> Anyone who uses test reports to determine whether a module works or not
> on their platform would look at the failure reports.
That's how it should be. But I've got different experience.
> CPAN "visitors" should have a minimum technical ability to decipher
> failure reports. If they are evaluating a module that may suit their
> needs, presumably they would not superficially ignore it just because it
> failed in some test reports.
>
> There are many types of failure reports, and often for reasons beyond
> the author's control.
>
> Accept that failures (and even strange unknown and na reports) happen.
I have absolutely no problem with "strange" failures.
But -- after checking a couple of different test reports from that
system -- this looked like a systematic, not a strange, problem to
me, and so I wrote a reply.
I run a smoke box (for the Perl core) myself that produces nothing
but failure reports, but that's because it tests configurations not
covered in other smokes.
> > 3) You install a compiler on your machine, or you stop that specific
> > smoke. There are already a couple of people who have set up
> > Windows smoke boxes. And your other smoke setups are fine, so
> > this suggestion really isn't meant offensive.
>
> So "visitors" would see that your module works on some Windows
> platforms, and not be too worried about failures.
>
> We need platforms without compilers to run tests, so that code which
> recognizes that there is no compiler and acts accordingly can be tested!
Agreed. But then we need the test tools to handle these
platforms correctly.
> I agree 100% with imacat here:
>
> > I'm providing my CPU, my harddisk, my bandwidth, my
> > time to help testing tens of new packages everyday.
>
> This is a volunteer effort. People are trying to contribute to the
> community, and they get little back for it. If they get criticised for
> trying to help out, then they'll stop helping out.
I know, and I really appreciate that. As I said above, CPAN testers
is great, and it would not exist without people like imacat.
OTOH, CPAN would not exist without people contributing to it.
I'm not unfamiliar with the concept of volunteer effort. I've
spent a reasonable amount of my free time over the last couple
of years writing CPAN modules, contributing to other modules and
to the Perl core.
> If you don't like what's happening, do something contructive like submit
> patches to ExtUtils::MakeMaker and Module::Build, CPANPLUS,
> Test::Reporter, CPAN::YACSmoke or CPAN::WWW::Testers to minimize failure
> reports like this one.
I'd love to, but currently I've reached the limit of what I can
do in my free time.
Best regards,
Marcus
--------------------- Original Message Ends --------------------
pgpIqFAoZRXtO.pgp
Description: PGP signature
