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
