It does help that Visual Studio ships with a batch file to open a console 
configured for using vc++. Just don't use that when working on D apps. 

On Feb 14, 2012, at 1:04 AM, Walter Bright <[email protected]> wrote:

> On 2/14/2012 12:50 AM, Vincent wrote:
>>>> * Improvement potential #3 -- Linker executable name.
>>>> 
>>>> The name [link.exe] conflicts with Microsoft's linker. Please name it
>>>> [optlink.exe].
>> 
>>> This is why we switched away from relying solely on environment variables, 
>>> such
>>> as PATH, to find the programs and set options. Instead, sc.ini is used:
>> 
>> Hi, Walter!
>> I support Alf in renaming initiative. Even if you were so smart to use 
>> sc.ini,
>> other vedors are not!
> 
> It's fine if they do not, as sc.ini is designed to override any path set in 
> the environment.
> 
> 
>> I put dmd/bin in PATH where dmd.exe can be found (obvious solution), BUT
>> link.exe sit at the same place!
>> Despite what dmd.exe uses, MS tools will catch wrong link.exe or dmd will 
>> catch
>> MS' link.exe (if you put MS tools first in PATH).
>> So it's MUCH easier to rename link.exe (it's not a trademark, what a 
>> problem!),
>> than spreading curses every time you get strange error from compiler.
>> Situation is that MS is dominating on the market, so DM should adapt its 
>> tools
>> to be most painless after you add 'em on computer.
>> 
>> Good luck!
> 
> I am loathe to break 20+ years of working makefiles.
> 
> But there is a simple solution for your case. Create a batch file, dmd.bat, 
> with the contents:
> 
>   c:\dmd\windows\bin\dmd %1 %2 %3 %4
> 
> and put it somewhere in your PATH. Then, dmd will run the correct dmd.exe 
> without it being on the PATH, and it will find the correct link.exe (because 
> of sc.ini). Meanwhile, if you just type link, it will find your MS-LINK.
> 
> But what most people do is have multiple .bat files, one for each compiler, 
> to switcheroo the environment for the compiler they wish to use at the 
> moment. After all, it isn't just link.exe. It's all the tools, the .h files, 
> the library files, etc.
> 

Reply via email to