Bug #49010 for Perl-Dist-Strawberry: Strawberry depends on PATH but doesn't set it properly

Tue Aug 25 19:22:16 2009 John.Wiersba [...] thomsonreuters.com - Ticket created

Subject:	Strawberry depends on PATH but doesn't set it properly
Date:	Tue, 25 Aug 2009 19:21:44 -0400
To:	<bug-Perl-Dist-Strawberry [...] rt.cpan.org>
From:	<John.Wiersba [...] thomsonreuters.com>

I have Activestate perl installed at the front of my "system" path. Strawberry in at the end of my "system" path. When I try to run c:\strawberry\perl\bin\cpan -i SOAP::Lite I get a popup error "This application has failed to start because libexpat.dll was not found. Re-installing the application may fix the problem." After adjusting my PATH, I no longer get that error. I believe that Strawberry should either: 1) (preferably) not depend on the PATH, or 2) force the PATH to a known good state when various commands and utilities start up. Thanks! -- John Wiersba

Tue Aug 25 19:50:52 2009 csjewell [...] cpan.org - Correspondence added

Subject:	libexpat.dll needs to have a unique name.
RT-Send-CC:	kmx [...] cpan.org

On Tue Aug 25 19:22:16 2009, John.Wiersba@thomsonreuters.com wrote: Show quoted text

> I have Activestate perl installed at the front of my "system" path. > Strawberry in at the end of my "system" path. When I try to run > c:\strawberry\perl\bin\cpan -i SOAP::Lite > I get a popup error "This application has failed to start because > libexpat.dll was not found. Re-installing the application may fix the > problem." > > After adjusting my PATH, I no longer get that error. I believe that > Strawberry should either: > 1) (preferably) not depend on the PATH, or > 2) force the PATH to a known good state when various commands and > utilities start up.

"Not found" in this case, I think really means "can't be loaded" because a copy of libexpat.dll that Strawberry can't load has been found in the path. It may be provided by ActiveState, it may be another program in the path. We don't really recommend having Activestate and Strawberry installed at the same time because of problems such as this. We're kind of stuck depending on the path when we load Windows .DLL's, because that's what Windows does. Unfortunately, we can't use your option #2 because we'd have to process the PATH using Perl code before Perl starts. We're trying to give a number of other .DLL's that are used by modules unique names in order to avoid this problem, and I'm CC-ing the person who's building those binaries for us in order to bring this particular one to his attention. (Note to kmx: libexpat.dll is in strawberry\perl\bin)

Tue Aug 25 19:50:54 2009 The RT System itself - Status changed from 'new' to 'open'

Tue Aug 25 19:50:57 2009 csjewell [...] cpan.org - Given to CSJEWELL

Tue Aug 25 19:51:54 2009 csjewell [...] cpan.org - Cc KMX added

Tue Aug 25 20:14:19 2009 csjewell [...] cpan.org - AdminCc KMX added

Tue Aug 25 20:14:19 2009 csjewell [...] cpan.org - Cc KMX deleted

Tue Aug 25 20:15:09 2009 csjewell [...] cpan.org - AdminCc KMX deleted

Tue Aug 25 20:15:09 2009 csjewell [...] cpan.org - AdminCc KMX added

Wed Aug 26 00:03:47 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Wed, 26 Aug 2009 14:03:23 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

Perl generally, and Strawberry specifically, does not support having multiple installations on the same host. A check is being added to Strawberry in the next release or so to catch these cases and prevent installation. Adam K 2009/8/26 John.Wiersba@thomsonreuters.com via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Tue Aug 25 19:22:16 2009: Request 49010 was acted upon. > Transaction: Ticket created by John.Wiersba@thomsonreuters.com > Queue: Perl-Dist-Strawberry > Subject: Strawberry depends on PATH but doesn't set it properly > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: John.Wiersba@thomsonreuters.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=49010 > > > > I have Activestate perl installed at the front of my "system" path. > Strawberry in at the end of my "system" path. When I try to run > c:\strawberry\perl\bin\cpan -i SOAP::Lite > I get a popup error "This application has failed to start because > libexpat.dll was not found. Re-installing the application may fix the > problem." > > After adjusting my PATH, I no longer get that error. I believe that > Strawberry should either: > 1) (preferably) not depend on the PATH, or > 2) force the PATH to a known good state when various commands and > utilities start up. > > Thanks! > -- John Wiersba > > > > I have Activestate perl installed at the front of my "system" path. Strawberry in at the end of my "system" path. When I try to run > c:\strawberry\perl\bin\cpan -i SOAP::Lite > I get a popup error "This application has failed to start because libexpat.dll was not found. Re-installing the application may fix the problem." > > After adjusting my PATH, I no longer get that error. I believe that Strawberry should either: > 1) (preferably) not depend on the PATH, or > 2) force the PATH to a known good state when various commands and utilities start up. > > Thanks! > -- John Wiersba > >

Wed Aug 26 12:18:13 2009 kmx [...] cpan.org - Correspondence added

Show quoted text

> We're kind of stuck depending on the path when we load Windows .DLL's, > because that's what Windows does. Unfortunately, we can't use your > option #2 because we'd have to process the PATH using Perl code before > Perl starts.

Well, it is not completely true: *) let us have e.g. c:\strawberry\perl\bin\cpan.bat *) if you put at the beginning of cpan.bat this line: set PATH=%~dp0;%~dp0..\..\c\bin;%PATH% *) you will force adding both strawberry bin dirs at the beginning of PATH I am not saying that I want to use it for some particular strawberry script, just saying that there is an option how to do some PATH-tricks without perl code. -- kmx

Wed Aug 26 14:21:34 2009 jrw32982 [...] yahoo.com - Correspondence added

On Wed Aug 26 00:03:47 2009, adam@ali.as wrote: Show quoted text

> Perl generally, and Strawberry specifically, does not support having > multiple installations on the same host.

Well, not really (for the "perl generally" part). On unix, I can install many versions of perl and even the same version multiple times. They just need to be installed in different locations. And this is exactly as it should be. Of course there can be only one "system" perl (in /usr/bin/perl). Since strawberry perl and activestate are in different locations, it would be great if, when I call strawberry, it uses its own DLLs and when I call activestate perl, it uses its own. -- John

Wed Aug 26 14:25:46 2009 jrw32982 [...] yahoo.com - Correspondence added

On Tue Aug 25 19:50:52 2009, CSJEWELL wrote: Show quoted text

> We don't really recommend having Activestate and Strawberry installed at > the same time because of problems such as this.

Well, I can understand this, but it makes it painful to try out strawberry when I've already got activestate installed. That's part of the rationale for allowing multiple installs of perl.exe. Show quoted text

> We're kind of stuck depending on the path when we load Windows .DLL's, > because that's what Windows does. Unfortunately, we can't use your > option #2 because we'd have to process the PATH using Perl code before > Perl starts.

Another option would be to start perl.exe, have it fix up the PATH, and then have it fork/exec itself (I know this is Windows -- I assume there's some way of doing that). -- John

Wed Aug 26 23:23:38 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Thu, 27 Aug 2009 13:23:14 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

All existing advice I've had is that putting your private path BEFORE the core Windows paths are considered a Bad Thing(TM). Theoretically, at most you put yours after the core windows path, but before any other paths. Adam K 2009/8/27 kmx via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > >

>> We're kind of stuck depending on the path when we load Windows .DLL's, >> because that's what Windows does. Unfortunately, we can't use your >> option #2 because we'd have to process the PATH using Perl code before >> Perl starts.

> > Well, it is not completely true: > > *) let us have e.g. c:\strawberry\perl\bin\cpan.bat > > *) if you put at the beginning of cpan.bat this line: > set PATH=%~dp0;%~dp0..\..\c\bin;%PATH% > > *) you will force adding both strawberry bin dirs at the beginning of PATH > > I am not saying that I want to use it for some particular strawberry > script, just saying that there is an option how to do some PATH-tricks > without perl code. > > -- > kmx >

Wed Aug 26 23:25:12 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Thu, 27 Aug 2009 13:24:50 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

For this case, you can use the Strawberry Portable package. It has to do extra work and so has slower Perl process startup, but does operate as a secondary install properly, EXCEPT for the installation of XS modules (as the gcc toolchain doesn't handle being portable yet). Adam K 2009/8/27 John Wiersba via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > > > On Tue Aug 25 19:50:52 2009, CSJEWELL wrote: >

>> We don't really recommend having Activestate and Strawberry installed at >> the same time because of problems such as this.

> > Well, I can understand this, but it makes it painful to try out > strawberry when I've already got activestate installed. That's part of > the rationale for allowing multiple installs of perl.exe. >

>> We're kind of stuck depending on the path when we load Windows .DLL's, >> because that's what Windows does. Unfortunately, we can't use your >> option #2 because we'd have to process the PATH using Perl code before >> Perl starts.

> > Another option would be to start perl.exe, have it fix up the PATH, and > then have it fork/exec itself (I know this is Windows -- I assume > there's some way of doing that). > > -- John > > > >

Thu Aug 27 02:21:19 2009 kmx [...] volny.cz - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Thu, 27 Aug 2009 08:20:57 +0200
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	kmx <kmx [...] volny.cz>

Show quoted text

> ... EXCEPT for the installation of XS modules (as the gcc toolchain > doesn't handle being portable yet). >

Adam, I don't wanna argue with you about strawberry guts but are you sure about that? Try for example a simple module YAML::Syck that has XS part: 1) put portable strawberry e.g. into c:\strange\subdir\strawberry 2) open command prompt and run: set PATH=c:\strange\subdir\strawberry\perl\bin;c:\strange\subdir\strawberry\c\bin;%PATH% 3) in the same command prompt run: cpan YAML::Syck 4) look into: c:\strange\subdir\strawberry\perl\site\lib\auto\YAML\Syck 5) it for me works (with 5.10.0.6 portable) IDEA: What about to put in the root of portable strawberry a very simple batch file e.g. "portableshell.bat" like this: @echo off set PATH=%~dp0\perl\bin;%~dp0\c\bin;%PATH% cmd It opens a command prompt with properly set PATH variable - so commands "perl", "cpan" & co. works as expected. And it should even work with another perl installed on the same machine - so it solve a situation when somebody wants just quickly try it as John (the author of this RT). Providing the mentioned "portableshell.bat" + brief "README.TXT" could save many questions on #win32 channel. -- kmx

Thu Aug 27 02:37:10 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Thu, 27 Aug 2009 16:36:50 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

Well if you add it to the path, of course it will work :) The problem is not so much creating a batch script at all, the problem is people being aware enough that it exists, and knowing to run it. Adam K 2009/8/27 kmx via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > > >

>> ... EXCEPT for the installation of XS modules (as the gcc toolchain >> doesn't handle being portable yet). >>

> Adam, I don't wanna argue with you about strawberry guts but are you > sure about that? > > Try for example a simple module YAML::Syck that has XS part: > 1) put portable strawberry e.g. into c:\strange\subdir\strawberry > 2) open command prompt and run: > set > PATH=c:\strange\subdir\strawberry\perl\bin;c:\strange\subdir\strawberry\c\bin;%PATH% > 3) in the same command prompt run: > cpan YAML::Syck > 4) look into: c:\strange\subdir\strawberry\perl\site\lib\auto\YAML\Syck > 5) it for me works (with 5.10.0.6 portable) > > IDEA: What about to put in the root of portable strawberry a very simple > batch file e.g. "portableshell.bat" like this: > @echo off > set PATH=%~dp0\perl\bin;%~dp0\c\bin;%PATH% > cmd > > It opens a command prompt with properly set PATH variable - so commands > "perl", "cpan" & co. works as expected. And it should even work with > another perl installed on the same machine - so it solve a situation > when somebody wants just quickly try it as John (the author of this RT). > > Providing the mentioned "portableshell.bat" + brief "README.TXT" could > save many questions on #win32 channel. > > -- > kmx > > >

Thu Aug 27 15:17:56 2009 kmx [...] volny.cz - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Thu, 27 Aug 2009 21:17:19 +0200
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	kmx <kmx [...] volny.cz>

Show quoted text

> The problem is not so much creating a batch script at all, the problem > is people being aware enough that it exists, and knowing to run it. >

What about portableshell.bat + README.TXT attached to this post? -- kmx

Download portable.zip
application/octet-stream 1.1k

Message body not shown because it is not plain text.

Mon Aug 31 03:08:05 2009 kmx [...] cpan.org - Correspondence added

Show quoted text

> > ... > > set PATH=c:\strange\subdir\strawberry\perl\bin;c:\strange\sub > > dir\strawberry\c\bin;%PATH% > > ...

Show quoted text

> > Well if you add it to the path, of course it will work :) >

But we need both dirs (...\perl\bin + ...\c\bin) in PATH anyway, as we have some important DLLs in ...\c\bin (e.g. libxml.dll) and modules using those DLLs (e.g. LibXML::XML) will not work without ...\c\bin in PATH. So providing we have ...\perl\bin + ...\c\bin in our PATH, is there any other reason why not to allow other install dir than c:\strawberry\? (I am speaking about 5.10.x). If portable 5.10.x works from "dir-of-user's-choice" why not to allow non-portable 5.10.x to be installed to "dir-of-user's-choice"? -- kmx

Mon Aug 31 07:09:36 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Mon, 31 Aug 2009 21:08:44 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

"OTHER" directory not really. The original lockdown was done because MOST of the natural places to install it have spaces in the directory names. And much of the toolchain (including the gcc parts) don't handle spaces very well. At some point, someone really needs to audit the toolchain to identify the root cases of all the places that rely on spaces. Adam K 2009/8/31 kmx via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > >

>> > ... >> > set PATH=c:\strange\subdir\strawberry\perl\bin;c:\strange\sub >> > dir\strawberry\c\bin;%PATH% >> > ...

>

>> >> Well if you add it to the path, of course it will work :) >>

> > But we need both dirs (...\perl\bin + ...\c\bin) in PATH anyway, as we > have some important DLLs in ...\c\bin (e.g. libxml.dll) and modules > using those DLLs (e.g. LibXML::XML) will not work without ...\c\bin in PATH. > > So providing we have ...\perl\bin + ...\c\bin in our PATH, is there any > other reason why not to allow other install dir than c:\strawberry\? (I > am speaking about 5.10.x). > > If portable 5.10.x works from "dir-of-user's-choice" why not to allow > non-portable 5.10.x to be installed to "dir-of-user's-choice"? > > -- > kmx >

Mon Aug 31 07:40:48 2009 kmx [...] volny.cz - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Mon, 31 Aug 2009 13:40:24 +0200
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	kmx <kmx [...] volny.cz>

OK, I know that spaces in dirnames confuse the toolchain and it is definitely better to avoid them. However what about to do a half-step: - allow other installation directory, not only fixed c:\strawberry - just refuse it in case it contains spaces or non-us-ascii characters I guess it should be feasible at least with strawberry 5.10.x. -- kmx Reserved Local Account via RT napsal(a): Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=49010 > > > "OTHER" directory not really. > > The original lockdown was done because MOST of the natural places to > install it have spaces in the directory names. > > And much of the toolchain (including the gcc parts) don't handle > spaces very well. > > At some point, someone really needs to audit the toolchain to identify > the root cases of all the places that rely on spaces. > > Adam K >

Tue Sep 01 02:33:31 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Tue, 1 Sep 2009 16:33:07 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

Feasible? Potentially yes. But I'd thought that without doing it "properly", doing it half-way in this case would just annoy people. Adam K 2009/8/31 kmx via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > > > OK, I know that spaces in dirnames confuse the toolchain and it is > definitely better to avoid them. > > However what about to do a half-step: > - allow other installation directory, not only fixed c:\strawberry > - just refuse it in case it contains spaces or non-us-ascii characters > > I guess it should be feasible at least with strawberry 5.10.x. > > -- > kmx > > Reserved Local Account via RT napsal(a):

>> Queue: Perl-Dist-Strawberry >> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=49010 > >> >> "OTHER" directory not really. >> >> The original lockdown was done because MOST of the natural places to >> install it have spaces in the directory names. >> >> And much of the toolchain (including the gcc parts) don't handle >> spaces very well. >> >> At some point, someone really needs to audit the toolchain to identify >> the root cases of all the places that rely on spaces. >> >> Adam K >>

> > >

Wed Sep 02 04:46:34 2009 kmx [...] volny.cz - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Wed, 02 Sep 2009 10:46:13 +0200
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	kmx <kmx [...] volny.cz>

OK, I see your point, Adam. I've done some research and found out: 1) we have to split this issue in two parts - spaces in the path - non-us-ascii characters in the path (this is much more tricky than it might look) 2) the first problem is dmake - it goes totally mad if you have dmake.exe in path containing spaces (it even doesn't start) - after some investigation I revealed a) problem inside dmake; b) poorly written ./startup/*.mk scripts As for the dmake itself I have prepared a patched version that solves "spaces-issue" - see patch: http://svn.ali.as/cpan/users/kmx/dmake_patch/dmake_svn-rev275670_patch.diff (I should perhaps post this patch proposal to dmake's issue tracker) I have also fixed *.mk scripts; the newly compiled dmake.exe incl. patched scripts is here: http://svn.ali.as/cpan/users/kmx/dmake_patch/dmake_svn-rev275670+kmx-patch.zip To test it: - delete c:\strawberry\c\bin\dmake.exe - delete the whole subdir c:\strawberry\c\bin\startup - unzip dmake_svn-rev275670+kmx-patch.zip into c:\strawberry\c\bin\ BTW: c:\strawberry\c\bin\startup deserves a bit of cleaning up anyway 3) After we have fixed dmake the other problem is with Makefiles generated by ExtUtils::MakeMaker as they simply do not use enough double-quotes so even if we take "space-aware" dmake it fails as the Makefile are simply not properly generated. So somebody should volunteer for making ExtUtils::MakeMaker ready for spaces in paths. 4) The gcc toolchain itself seems to be quite ok with pathnames containing spaces; however it cannot be extensively tested till somebody fixes ExtUtils::MakeMaker (see point 3). 5) And completely different story are non-us-ascii charcters in path name (dmake explicitly refuses them at the moment). To sum up: - putting the patched dmake (accepting spaces in path) into strawberry might be a good idea right now - without fixing ExtUtils::MakeMaker no chance to move forward - so we are probably gonna stay at fixed c:\strawberry\ (or recommending portable edition as an option) We should probably start a new RT for this issue. -- kmx Reserved Local Account via RT napsal(a): Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > > > Feasible? Potentially yes. > > But I'd thought that without doing it "properly", doing it half-way in > this case would just annoy people. > > Adam K >

Wed Sep 02 06:36:57 2009 adam [...] ali.as - Correspondence added

Subject:	Re: [rt.cpan.org #49010] Strawberry depends on PATH but doesn't set it properly
Date:	Wed, 2 Sep 2009 20:36:36 +1000
To:	bug-Perl-Dist-Strawberry [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

We've sent changes for dmake to the author in the past (when we were first trying to escape nmake) and he seemed pretty responsive. I don't like patching things as a rule (with, of course, minor exceptions as a last resort) as it increases the maintenance burden and reduces correctness, so lets see if we can reach out to him and get the changes applied there instead as the first step. If we have a space-legal dmake, there's a much greater case for making the changes to ExtUtils::MakeMaker, as it becomes the weakest link in the chain. I concur on the new ticket thing. Adam K 2009/9/2 kmx via RT <bug-Perl-Dist-Strawberry@rt.cpan.org>: Show quoted text

> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > > > OK, I see your point, Adam. > > I've done some research and found out: > > 1) we have to split this issue in two parts > - spaces in the path > - non-us-ascii characters in the path (this is much more tricky than it > might look) > > 2) the first problem is dmake > - it goes totally mad if you have dmake.exe in path containing spaces > (it even doesn't start) > - after some investigation I revealed a) problem inside dmake; b) poorly > written ./startup/*.mk scripts > > As for the dmake itself I have prepared a patched version that solves > "spaces-issue" - see patch: > http://svn.ali.as/cpan/users/kmx/dmake_patch/dmake_svn-rev275670_patch.diff > (I should perhaps post this patch proposal to dmake's issue tracker) > > I have also fixed *.mk scripts; the newly compiled dmake.exe incl. > patched scripts is here: > http://svn.ali.as/cpan/users/kmx/dmake_patch/dmake_svn-rev275670+kmx-patch.zip > > To test it: > - delete c:\strawberry\c\bin\dmake.exe > - delete the whole subdir c:\strawberry\c\bin\startup > - unzip dmake_svn-rev275670+kmx-patch.zip into c:\strawberry\c\bin\ > > BTW: c:\strawberry\c\bin\startup deserves a bit of cleaning up anyway > > 3) After we have fixed dmake the other problem is with Makefiles > generated by ExtUtils::MakeMaker as they simply do not use enough > double-quotes so even if we take "space-aware" dmake it fails as the > Makefile are simply not properly generated. So somebody should volunteer > for making ExtUtils::MakeMaker ready for spaces in paths. > > 4) The gcc toolchain itself seems to be quite ok with pathnames > containing spaces; however it cannot be extensively tested till somebody > fixes ExtUtils::MakeMaker (see point 3). > > 5) And completely different story are non-us-ascii charcters in path > name (dmake explicitly refuses them at the moment). > > To sum up: > - putting the patched dmake (accepting spaces in path) into strawberry > might be a good idea right now > - without fixing ExtUtils::MakeMaker no chance to move forward > - so we are probably gonna stay at fixed c:\strawberry\ (or recommending > portable edition as an option) > > We should probably start a new RT for this issue. > > -- > kmx > > Reserved Local Account via RT napsal(a):

>> Queue: Perl-Dist-Strawberry >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49010 > >> >> Feasible? Potentially yes. >> >> But I'd thought that without doing it "properly", doing it half-way in >> this case would just annoy people. >> >> Adam K >>

> > >

Wed Sep 02 23:44:59 2009 kmx [...] cpan.org - Correspondence added

Show quoted text

> I concur on the new ticket thing.

OK, "spaces-in-dirname" issue moved to: http://rt.cpan.org/Ticket/Display.html?id=49388

Wed Sep 23 22:32:58 2009 csjewell [...] cpan.org - Dependency by ticket #49957 added

Mon Sep 28 02:12:48 2009 csjewell [...] cpan.org - Severity Wishlist added

Mon Oct 12 03:17:45 2009 csjewell [...] cpan.org - Status changed from 'open' to 'patched'

Wed Oct 28 13:36:38 2009 csjewell [...] cpan.org - Correspondence added

Resolving since October release happened.

Wed Oct 28 13:36:39 2009 The RT System itself - Status changed from 'patched' to 'open'

Wed Oct 28 13:36:41 2009 csjewell [...] cpan.org - Status changed from 'open' to 'resolved'