From @rurban

This is a bug report for perl from rurban@​cpanel.net,
generated with the help of perlbug 1.39 running under perl 5.15.8.

win32 lacks usability with a default install, and the
workarounds are poorly documented.

1. SITELIB is not in the @​INC path with a default install, as
perl.c overrides the config.h definitions with a custom and
undocumented registry search. This registry entry is fine for
vendor packagers, but is not created by the default installation.

Either keep the sitelib/sitearch and vendorlib/vendorarch default
entries in config.h and allow overrides from the registry (similar to PERL5LIB).

Or create the necessary registry entry in installperl.
Better not. Registry entries should be optional.

The problem is that one cannot install further modules without proper sitelib/arch
entries in @​INC via cpan.

README.win32 says​:
Perl does not depend on the registry, but it can look up certain default
values if you choose to put them there.

This is wrong. Without a registry for sitelib entry cpan installations
will silently fail. "Cannot find ..." even if they are installed correctly.

2. CPAN creates unusable default entries in .cpan\CPAN\MyConfig.pm
See [CPAN #76831]. nmake is added with the full path, which usually
contains spaces, which are not quoted. The nmake test system call
passes interestingly, nmake install fails with cpan.

-----------------------------------------------------------------
---
Flags:
category=install
severity=medium
---
Site configuration information for perl 5.15.8:

Configured by rurban at Wed Apr 25 11:02:45 2012.

Summary of my perl5 (revision 5 version 15 subversion 8) configuration:

Platform:
osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO',
optimize='-Od -MD -Zi -DDEBUGGING',
cppflags='-DWIN32'
ccversion='15.00.30729.01', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -libpath:"c:\perl516\5.15.9\lib\MSWin32-x86-multi-thread\CORE" -machine:x86 "/manifestdependency:type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"'
libpth=\lib
libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl515.lib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -libpath:"c:\perl516\5.15.9\lib\MSWin32-x86-multi-thread\CORE" -machine:x86 "/manifestdependency:type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"'

Locally applied patches:


---
@INC for perl 5.15.8:
c:\perl516\site\5.15.9\lib/MSWin32-x86-multi-thread
c:\perl516\site\5.15.9\lib (via registry)
C:/perl516/5.15.9/lib/MSWin32-x86-multi-thread
C:/perl516/5.15.9/lib
.

---
Environment for perl 5.15.8:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=C:\perl516\5.15.9\bin;C:\perl516\5.15.9\bin\MSWin32-x86-multi-thread;C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
PERL_BADLANG (unset)
SHELL (unset)

From @rjbs

* "rurban@​cpanel.net" <perlbug-followup@​perl.org> [2012-04-26T17​:13​:26]

1. SITELIB is not in the @​INC path with a default install, as
...
README.win32 says​:
Perl does not depend on the registry, but it can look up certain default
values if you choose to put them there.

This is wrong. Without a registry for sitelib entry cpan installations
will silently fail. "Cannot find ..." even if they are installed correctly.

and

2. CPAN creates unusable default entries in .cpan\CPAN\MyConfig.pm
See [CPAN #76831]. nmake is added with the full path, which usually
contains spaces, which are not quoted. The nmake test system call
passes interestingly, nmake install fails with cpan.

Are these regressions, or problems existing in 5.14 as well?

--
rjbs

The RT System itself - Status changed from 'new' to 'open'

From @rurban

On Wed, May 2, 2012 at 9​:28 PM, Ricardo Signes
<perl.p5p@​rjbs.manxome.org> wrote​:

* "rurban@​cpanel.net" <perlbug-followup@​perl.org> [2012-04-26T17​:13​:26]

1. SITELIB is not in the @​INC path with a default install, as
...
README.win32 says​:
Perl does not depend on the registry, but it can look up certain default
values if you choose to put them there.

This is wrong. Without a registry for sitelib entry cpan installations
will silently fail. "Cannot find ..." even if they are installed correctly.

and

2. CPAN creates unusable default entries in .cpan\CPAN\MyConfig.pm
See [CPAN #76831]. nmake is added with the full path, which usually
contains spaces, which are not quoted. The nmake test system call
passes interestingly, nmake install fails with cpan.

Are these regressions, or problems existing in 5.14 as well?

Sorry, I will not able to check these questions in the next two weeks.
--
Reini Urban
http​://cpanel.net/   http​://www.perl-compiler.org/

From @steve-m-hay

On 6 May 2012 14​:22, Reini Urban <rurban@​x-ray.at> wrote​:

On Wed, May 2, 2012 at 9​:28 PM, Ricardo Signes
<perl.p5p@​rjbs.manxome.org> wrote​:

* "rurban@​cpanel.net" <perlbug-followup@​perl.org> [2012-04-26T17​:13​:26]

1. SITELIB is not in the @​INC path with a default install, as
...
README.win32 says​:
Perl does not depend on the registry, but it can look up certain default
values if you choose to put them there.

This is wrong. Without a registry for sitelib entry cpan installations
will silently fail. "Cannot find ..." even if they are installed correctly.

and

2. CPAN creates unusable default entries in .cpan\CPAN\MyConfig.pm
See [CPAN #76831]. nmake is added with the full path, which usually
contains spaces, which are not quoted. The nmake test system call
passes interestingly, nmake install fails with cpan.

Are these regressions, or problems existing in 5.14 as well?

Sorry, I will not able to check these questions in the next two weeks.

I don't understand what the problem is with the first point, and can
only say that I thought that site\lib and lib were always
automatically added to @​INC if they existed in the folders next to
bin, and that this (still) works fine for me. I've never had any need
for any perl registry entries and still have no need for them now.
(Indeed, I was in favour of removing the code from the end of
win32_getenv() that checks for registry entries when that subject came
up once before since it too easily allows one perl installation to
break another...)

However, the second point is indeed a problem, but not a regression
from 5.14.2. In a default build of both 5.14.2 and of blead (both
using VC++ 2010) I find that "install URI" is able to make and test
the module fine, but then complains about "C​:\Program" [i.e. the
command is truncated at the first space...] when running the "nmake
install" command​:

"C​:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\nmake.EXE" -- OK

"C​:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\nmake.EXE"
test -- OK

C​:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\nmake.EXE
install -- NOT OK
'C​:\Program' is not recognized as an internal or external command,
operable program or batch file.

It would be nice to have that fixed for 5.16, even though 5.14 was the
same. In fact 5.12.4 is the same too. It's probably been like that
since forever, which may be partly why I've never used cpan :-(

From @steve-m-hay

Can this ticket be closed?

1. site/lib and lib are both in the default @​INC in a default installation. No registry entries are required for CPAN to work out of the box.

2. cpan #76831 is resolved, fixing this issue.

(I've just reconfirmed both of these things using a default build of 5.28.2.)

From [Unknown Contact. See original ticket]

Can this ticket be closed?

1. site/lib and lib are both in the default @​INC in a default installation. No registry entries are required for CPAN to work out of the box.

2. cpan #76831 is resolved, fixing this issue.

(I've just reconfirmed both of these things using a default build of 5.28.2.)

I'm closing this ticket due to lack of response.