Jump to page: 1 2
Thread overview
Visual D 0.3.40 unable to build projects under path names with spaces
Feb 01, 2015
finalpatch
Feb 02, 2015
Rainer Schuetze
Feb 02, 2015
finalpatch
Feb 02, 2015
Rainer Schuetze
Feb 03, 2015
finalpatch
Feb 03, 2015
finalpatch
Feb 03, 2015
Rainer Schuetze
Feb 04, 2015
finalpatch
Feb 08, 2015
Rainer Schuetze
May 30, 2019
Obsidian Jackal
May 31, 2019
Rainer Schuetze
Jun 01, 2019
Obsidian Jackal
February 01, 2015
It took me some time to figure out 0.3.40 does not like path names that contain spaces.  The default Visual Studio 2013 project folder happens to be such a directory (%USERPROFILE%\Documents\Visual Studio 2013\Projects) so after a fresh install of 0.3.40 it would appear that none of the project template works, which is going to be very frustrating for newcomers.
This issue is new to 0.3.40. The previous release 0.3.39 is okay with spaces in project paths.
February 02, 2015

On 01.02.2015 14:49, finalpatch wrote:
> It took me some time to figure out 0.3.40 does not like path names that
> contain spaces.  The default Visual Studio 2013 project folder happens
> to be such a directory (%USERPROFILE%\Documents\Visual Studio
> 2013\Projects) so after a fresh install of 0.3.40 it would appear that
> none of the project template works, which is going to be very
> frustrating for newcomers.
> This issue is new to 0.3.40. The previous release 0.3.39 is okay with
> spaces in project paths.

I don't see this issue. Please file it at https://issues.dlang.org/ providing the *.build.cmd and the *.buildlog.htl from the output folder.
February 02, 2015
Hi Rainer,

Are you saying you don't see this issue with the latest development branch?
I was referring to the prebuilt 0.3.40 binary at
https://github.com/D-Programming-Language/visuald/releases , so maybe this has been fixed in the repo.

To be precise, the project templates can generate valid projects, but because the build commands created by visuald do not quote the path correctly, the project fails to link, and results in weird link errors, such as unable to link "user.lib" or "studio.lib".

On Monday, 2 February 2015 at 07:36:56 UTC, Rainer Schuetze wrote:
>
>
> On 01.02.2015 14:49, finalpatch wrote:
>> It took me some time to figure out 0.3.40 does not like path names that
>> contain spaces.  The default Visual Studio 2013 project folder happens
>> to be such a directory (%USERPROFILE%\Documents\Visual Studio
>> 2013\Projects) so after a fresh install of 0.3.40 it would appear that
>> none of the project template works, which is going to be very
>> frustrating for newcomers.
>> This issue is new to 0.3.40. The previous release 0.3.39 is okay with
>> spaces in project paths.
>
> I don't see this issue. Please file it at https://issues.dlang.org/ providing the *.build.cmd and the *.buildlog.htl from the output folder.

February 02, 2015

On 02.02.2015 11:35, finalpatch wrote:
> Hi Rainer,
>
> Are you saying you don't see this issue with the latest development branch?
> I was referring to the prebuilt 0.3.40 binary at
> https://github.com/D-Programming-Language/visuald/releases , so maybe
> this has been fixed in the repo.
>
> To be precise, the project templates can generate valid projects, but
> because the build commands created by visuald do not quote the path
> correctly, the project fails to link, and results in weird link errors,
> such as unable to link "user.lib" or "studio.lib".

There are no changes since that release yet, so I'm on the same version but some local changes to the mago debugger engine.

Please post the *.build.cmd file from the output folder here. Mine looks like this (with bad lin breaks shown in my mail program):

set PATH=m:\s\d\rainers\windows\\bin;C:\Program Files (x86)\Windows Kits\8.1\\\bin;%PATH%
dmd -g -debug -X -Xf"Debug\Console_App6.json" -deps="Debug\Console_App6.dep" -c -od"Debug" main.d
if errorlevel 1 goto reportError

set LIB="m:\s\d\rainers\windows\bin\..\..\lib"
echo. > c:\users\rainer\DOCUME~1\VISUAL~1\Projects\COCE3D~1\Debug\CONSOL~1.LNK
echo "Debug\main.obj","Debug\Console_App6.exe_cv","Debug\Console_App6.map",user32.lib+ >> c:\users\rainer\DOCUME~1\VISUAL~1\Projects\COCE3D~1\Debug\CONSOL~1.LNK
echo kernel32.lib/NOMAP/CO/NOI/DELEXE >> c:\users\rainer\DOCUME~1\VISUAL~1\Projects\COCE3D~1\Debug\CONSOL~1.LNK

"C:\Program Files (x86)\VisualD\pipedmd.exe" -deps Debug\Console_App6.lnkdep m:\s\d\rainers\windows\bin\link.exe @c:\users\rainer\DOCUME~1\VISUAL~1\Projects\COCE3D~1\Debug\CONSOL~1.LNK
if errorlevel 1 goto reportError
if not exist "Debug\Console_App6.exe_cv" (echo "Debug\Console_App6.exe_cv" not created! && goto reportError)
echo Converting debug information...
"C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" "Debug\Console_App6.exe_cv" "Debug\Console_App6.exe"
if errorlevel 1 goto reportError
if not exist "Debug\Console_App6.exe" (echo "Debug\Console_App6.exe" not created! && goto reportError)

goto noError

:reportError
echo Building Debug\Console_App6.exe failed!

:noError

-----------
Maybe there is something wrong with the "short" names?
February 03, 2015
You are absolutely right! I remember I have disabled short file names on my NTFS volume that's why long names with space get in there!


On Monday, 2 February 2015 at 19:06:08 UTC, Rainer Schuetze wrote:
> Maybe there is something wrong with the "short" names?

February 03, 2015
FYI, here's the cmd file

set PATH=C:\Users\fengli\Apps\dmd2\windows\bin;C:\Program Files (x86)\Microsoft Visual Studio 12.0\\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\\bin;%PATH%
dmd -g -debug -X -Xf"Debug\ConsoleApp1.json" -deps="Debug\ConsoleApp1.dep" -c -of"Debug\ConsoleApp1.obj" main.d
if errorlevel 1 goto reportError

set LIB="C:\Users\fengli\Apps\dmd2\windows\bin\..\lib"
echo. > c:\users\fengli\documents\visual studio 2013\Projects\ConsoleApp1\ConsoleApp1\Debug\ConsoleApp1.build.lnkarg
echo "Debug\ConsoleApp1.obj","Debug\ConsoleApp1.exe_cv","Debug\ConsoleApp1.map",user32.lib+ >> c:\users\fengli\documents\visual studio 2013\Projects\ConsoleApp1\ConsoleApp1\Debug\ConsoleApp1.build.lnkarg
echo kernel32.lib/NOMAP/CO/NOI/DELEXE >> c:\users\fengli\documents\visual studio 2013\Projects\ConsoleApp1\ConsoleApp1\Debug\ConsoleApp1.build.lnkarg

"C:\Program Files (x86)\VisualD\pipedmd.exe" -deps Debug\ConsoleApp1.lnkdep C:\Users\fengli\Apps\dmd2\windows\bin\link.exe @c:\users\fengli\documents\visual studio 2013\Projects\ConsoleApp1\ConsoleApp1\Debug\ConsoleApp1.build.lnkarg
if errorlevel 1 goto reportError
if not exist "Debug\ConsoleApp1.exe_cv" (echo "Debug\ConsoleApp1.exe_cv" not created! && goto reportError)
echo Converting debug information...
"C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" "Debug\ConsoleApp1.exe_cv" "Debug\ConsoleApp1.exe"
if errorlevel 1 goto reportError
if not exist "Debug\ConsoleApp1.exe" (echo "Debug\ConsoleApp1.exe" not created! && goto reportError)

goto noError

:reportError
echo Building Debug\ConsoleApp1.exe failed!

:noError


On Tuesday, 3 February 2015 at 10:08:38 UTC, finalpatch wrote:
> You are absolutely right! I remember I have disabled short file names on my NTFS volume that's why long names with space get in there!
>
>
> On Monday, 2 February 2015 at 19:06:08 UTC, Rainer Schuetze wrote:
>> Maybe there is something wrong with the "short" names?

February 03, 2015

On 03.02.2015 11:08, finalpatch wrote:
> You are absolutely right! I remember I have disabled short file names on
> my NTFS volume that's why long names with space get in there!
>
>
> On Monday, 2 February 2015 at 19:06:08 UTC, Rainer Schuetze wrote:
>> Maybe there is something wrong with the "short" names?
>


I didn't know it was possible to disable these...

Unfortunately, optlink (the linker that comes with dmd) fails to work for some cases when there are spaces in the filename, e.g. the response file name. Visual D could avoid that by specifying relative paths, if the spaces are in a name of a parent directory. But it still fails if your output directory name contains spaces (e.g. by reusing the configuration name).

Visual D provide some fallback for most cases if the short name conversion fails, though.
February 04, 2015
Hi Rainer,

So I installed 0.3.39 again and observed its build.cmd file,  it seems 0.3.39 uses relative paths. Here's 0.3.39's commands:

set PATH=C:\Users\fengli\Apps\dmd2\windows\bin;C:\Program Files (x86)\Microsoft Visual Studio 12.0\\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\\bin;%PATH%
dmd -g -debug -X -Xf"Debug\ConsoleApp1.json" -deps="Debug\ConsoleApp1.dep" -c -of"Debug\ConsoleApp1.obj" main.d
if errorlevel 1 goto reportError

set LIB="C:\Users\fengli\Apps\dmd2\windows\bin\..\lib"
echo. > Debug\ConsoleApp1.build.lnkarg
echo "Debug\ConsoleApp1.obj","Debug\ConsoleApp1.exe_cv","Debug\ConsoleApp1.map",user32.lib+ >> Debug\ConsoleApp1.build.lnkarg
echo kernel32.lib/NOMAP/CO/NOI/DELEXE >> Debug\ConsoleApp1.build.lnkarg

"C:\Program Files (x86)\VisualD\pipedmd.exe" -deps Debug\ConsoleApp1.lnkdep C:\Users\fengli\Apps\dmd2\windows\bin\link.exe @Debug\ConsoleApp1.build.lnkarg
if errorlevel 1 goto reportError
if not exist "Debug\ConsoleApp1.exe_cv" (echo "Debug\ConsoleApp1.exe_cv" not created! && goto reportError)
echo Converting debug information...
"C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" "Debug\ConsoleApp1.exe_cv" "Debug\ConsoleApp1.exe"
if errorlevel 1 goto reportError
if not exist "Debug\ConsoleApp1.exe" (echo "Debug\ConsoleApp1.exe" not created! && goto reportError)

goto noError

:reportError
echo Building Debug\ConsoleApp1.exe failed!

:noError


On Tuesday, 3 February 2015 at 21:24:26 UTC, Rainer Schuetze wrote:
>
>
> I didn't know it was possible to disable these...
>
> Unfortunately, optlink (the linker that comes with dmd) fails to work for some cases when there are spaces in the filename, e.g. the response file name. Visual D could avoid that by specifying relative paths, if the spaces are in a name of a parent directory. But it still fails if your output directory name contains spaces (e.g. by reusing the configuration name).
>
> Visual D provide some fallback for most cases if the short name conversion fails, though.

February 08, 2015

On 04.02.2015 09:07, finalpatch wrote:
> So I installed 0.3.39 again and observed its build.cmd file,  it seems
> 0.3.39 uses relative paths. Here's 0.3.39's commands:

There were problems with configurations that had spaces in the name. That's why the short name translation was added, but that also included creating an absolute path. I can't remember the exact problem, so I've now added a fix by placing the response file into the project folder instead of the output folder if short name generation failed.
May 30, 2019
This a problem still with v0.49.2
« First   ‹ Prev
1 2