Well, then, I made another mistake again. ^^; I was checking Compress::Bzip2's code to see why the FAIL reports weren't sent, and mixed up that page with the CPANPLUS's page when finding CPANPLUS's author.
I'm forwarding this whole thread to Jos Boumans (author of CPANPLUS),
Michael G Schwern (author of ExtUtils::MakeMaker) and the module-authors'
list.
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 --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Rob Janes <[EMAIL PROTECTED]>
To: Randy Kobes <[EMAIL PROTECTED]>
Date: Thu, 16 Jun 2005 12:20:45 -0400
Subject: Re: Fw: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
well, i only maintain Compress::Bzip2, not CPANPLUS.
Compress::Bzip2 is a perl xs module. you cannot install it without a c
compiler. I think it's a prereq. maybe something appropriate for the
yaml file, that CPAN/PLUS, Build.PL or Makefile.PL will catch.
the yaml file is generated by Makefile.PL or Build, not h2xs, from
parameters to the generating function.
I'm of the opinion a cc prereq should be in the yaml generated by
Makefile.PL or Build.PL, and therefore should be part of Module::Build
or ExtUtils::MakeMaker. CPAN/PLUS should look in the yaml for info put
there by Module::Build or ExtUtils::MakeMaker.
I don't think h2xs or other such low level parts of perl core should be
doing this.
I don't think I should put anything into Compress::Bzip2 to handle this,
although it is easy enough to do. What I would do is check for
$Config{cc}, and die pronto if it's not set. How big an issue is this?
Sorry, I wasn't a part of the original thread.
-rob
Randy Kobes wrote:
>On Thu, 16 Jun 2005, imacat wrote:
>
>
>
>> 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.
>>
>>
>
>It seems to me that this issue should be decided at the
>level of the Perl core, since this is responsible for
>writing the glue for XS-based modules. If it was decided
>that certain %Config entries should not be trusted, then it
>would be more efficient to handle this at the core level,
>rather than having every module author put in the same
>checks.
>
>
>
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Randy Kobes <[EMAIL PROTECTED]>
To: imacat <[EMAIL PROTECTED]>
Date: Thu, 16 Jun 2005 11:51:48 -0500 (CDT)
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
On Thu, 16 Jun 2005, imacat wrote:
> On Thu, 16 Jun 2005 09:47:31 -0500 (CDT)
> Randy Kobes <[EMAIL PROTECTED]> wrote:
> > It seems to me that this issue should be decided at the
> > level of the Perl core, since this is responsible for
> > writing the glue for XS-based modules. If it was decided
> > that certain %Config entries should not be trusted, then it
> > would be more efficient to handle this at the core level,
> > rather than having every module author put in the same
> > checks.
>
> http://search.cpan.org/dist/perl/configpm
> The Config module contains all the information that was available to the
> Configure program at Perl *****build time***** (over 900 values).
>
> This is not a kind of question that worths answering.
I'm not sure how to interpret this last comment.
All I was suggesting was that this issue has implications
beyond CPANPLUS; for example, many places in ExtUtils::*
seems to assume %Config has valid entries.
Ken Williams' ExtUtils::CBuilder (which is due to be
integrated into the perl core) seems to think that this
question is worth answering; the have_compiler() method
there tests if a working C compiler and linker is available,
by actually compiling and testing a sample C library.
--
best regards,
randy
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: Marcus Holland-Moritz <[EMAIL PROTECTED]>
To: Rob Janes <[EMAIL PROTECTED]>
Date: Thu, 16 Jun 2005 19:04:11 +0200
Subject: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0
----
On 2005-06-16, at 12:20:45 -0400, Rob Janes wrote:
> well, i only maintain Compress::Bzip2, not CPANPLUS.
>
> Compress::Bzip2 is a perl xs module. you cannot install it without a c
> compiler. I think it's a prereq. maybe something appropriate for the
> yaml file, that CPAN/PLUS, Build.PL or Makefile.PL will catch.
>
> the yaml file is generated by Makefile.PL or Build, not h2xs, from
> parameters to the generating function.
>
> I'm of the opinion a cc prereq should be in the yaml generated by
> Makefile.PL or Build.PL, and therefore should be part of Module::Build
> or ExtUtils::MakeMaker. CPAN/PLUS should look in the yaml for info put
> there by Module::Build or ExtUtils::MakeMaker.
Agreed.
> I don't think h2xs or other such low level parts of perl core should be
> doing this.
Yes, h2xs is just a starter for writing modules. It's just generating
templates. It doesn't know if the module, when finished, will need a
compiler or not (since modules can be hybrid).
> I don't think I should put anything into Compress::Bzip2 to handle this,
> although it is easy enough to do. What I would do is check for
> $Config{cc}, and die pronto if it's not set. How big an issue is this?
It doesn't make much sense to check for $Config{cc} as that is set
by Configure at perl build time, where a compiler _must_ have been
available. So this is always set, unless you delete it by hand.
You'd have to check if $Config{cc} works. This is also doable with
less than 50 lines of code, but it's IMO too much effort for a
modules that require a compiler.
Module::Build has a method have_c_compiler() that you can use to do
that check if your distribution is based on M::B instead of EU::MM.
Marcus
> Sorry, I wasn't a part of the original thread.
>
> -rob
>
> Randy Kobes wrote:
>
> >On Thu, 16 Jun 2005, imacat wrote:
> >
> >
> >
> >> 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.
> >>
> >>
> >
> >It seems to me that this issue should be decided at the
> >level of the Perl core, since this is responsible for
> >writing the glue for XS-based modules. If it was decided
> >that certain %Config entries should not be trusted, then it
> >would be more efficient to handle this at the core level,
> >rather than having every module author put in the same
> >checks.
> >
> >
> >
>
--
Computers will not be perfected until they can compute how much more
than the estimate the job will cost.
th
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: "Barbie" <[EMAIL PROTECTED]>
To: "imacat" <[EMAIL PROTECTED]>, "Marcus Holland-Moritz" <[EMAIL
PROTECTED]>, "Robert Rothenberg" <[EMAIL PROTECTED]>, "Randy Kobes" <[EMAIL
PROTECTED]>, "Rob Janes" <[EMAIL PROTECTED]>
Date: Thu, 16 Jun 2005 22:12:50 +0100
Subject: Failing Reports due to 3rd Party Software (was Fw: Re: FAIL
Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0)
----
Apologies to all if you get this twice. I sent it this morning, but it
doesn't appear to have got through my webmail ISP......
Hi folks,
This is a known problem with CPANPLUS. Unfortunately the reports are being
produced because currently CPANPLUS reports any failure in the
prepare/compile
stage as a failure. It doesn't interrogate why. It used to just fail, and
not
produce a report, but unfortunately as of version 0.050 the internals for
the
prepare/compile stage have been rewritten and the check has been removed.
I'm
currently looking at this, and have isolated where the problem is, but have
yet
to get it working with the test suite.
However, the conversation thread brings up another issue that has been
floating
around for some time. External libraries and apps that are pertinent to a
successful test suite, may not be available or installed on the smoke box. I
agree with Robert and Imacat that these should be flagged, so that anyone
looking at the cpan-testers web pages will know that there isn't a
straightforward install involved. In my opinion that report should be
something
other than FAIL, UNKNOWN or NA, as those have specific meanings. To be
honest
I'm not really sure the 'PERL_IS_TOO_LOW' check should be an NA report
either.
There needs to some other report type that indicates the build could not
continue due to external factors. Any "visitors" would then at least know
that
they need to read the README, at the very least, to see what extra software
they
need. As to what to call this other report I don't know. I've been thinking
about this for over a year and still haven't thought of anything suitable.
The
closest I got was UNGRADED.
If you guys think this is a suitable report, then I can certainly look to
expanding this in CPANPLUS and CPAN::YACSmoke, however there are other
testing/reporting mechanisms used by cpan-testers and we should really have
a
consensual agreement from interested parties that this is something worth
doing.
It will mean a change to WWW::CPAN::Testers(::Generator)? too.
I am not sending this to the cpan-testers list, as I don't think that that
is
necessarily the place to continue the thread, but am a little unsure of
where to
send it. module-authors? perl-qa? Suggestions on a postcard ;)
Cheers,
Barbie.
--
Barbie (@missbarbell.co.uk) | Birmingham Perl Mongers user group |
http://birmingham.pm.org/
--------------------- Original Message Ends --------------------
Forwarded by imacat <[EMAIL PROTECTED]>
----------------------- Original Message -----------------------
From: imacat <[EMAIL PROTECTED]>
To: Perl CPAN Testers <[email protected]>
Date: Fri, 17 Jun 2005 09:42:37 +0800
Subject: Re: Failing Reports due to 3rd Party Software (was Fw: Re: FAIL
Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0)
----
On Thu, 16 Jun 2005 22:12:50 +0100
"Barbie" <[EMAIL PROTECTED]> wrote:
> However, the conversation thread brings up another issue that has been
> floating
> around for some time. External libraries and apps that are pertinent to a
> successful test suite, may not be available or installed on the smoke box. I
> agree with Robert and Imacat that these should be flagged, so that anyone
> looking at the cpan-testers web pages will know that there isn't a
> straightforward install involved. In my opinion that report should be
> something
> other than FAIL, UNKNOWN or NA, as those have specific meanings. To be
> honest
> I'm not really sure the 'PERL_IS_TOO_LOW' check should be an NA report
> either.
> There needs to some other report type that indicates the build could not
> continue due to external factors. Any "visitors" would then at least know
> that
> they need to read the README, at the very least, to see what extra software
> they
> need. As to what to call this other report I don't know. I've been thinking
> about this for over a year and still haven't thought of anything suitable.
> The
> closest I got was UNGRADED.
From my personal experience dealing with GNU autoconf and automake,
I think the module author should be responsible to specify what external
executables, libraries, versions are required. Then ExtUtils::MakeMaker
can produce a certain error checking them before generating the Makefile,
and CPANPLUS can then capture that error and know some external
prerequisites failures.
I think I was wrong on this issue. This is not only CPANPLUS's
responsibility. ExtUtils::MakeMaker should return certain status or
message to notify CPANPLUS for that.
> I am not sending this to the cpan-testers list, as I don't think that that
> is
> necessarily the place to continue the thread, but am a little unsure of
> where to
> send it. module-authors? perl-qa? Suggestions on a postcard ;)
Personally I think module-authors is OK, in the case that all
relevant parties are all on module-authors.
--
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 --------------------
pgpAALlRnh4BF.pgp
Description: PGP signature
