Bug 15105 – paths never work

I've run into yet more cases where default configuration seems to fail. I'm trying to 'Compile and Disassemble', and my compiler is set to LDC (x64 build). It just says: 'ldc2' is not recognized as an internal or external command, operable program or batch file. In the options -> 'LDC install path', I have the LDC install path (not /bin) I have also tried to set that to the /bin subdirectory, it doesn't work either way. When I press F7 to build, it does build. It's like it can find LDC when building, but not when disassembling...? Getting paths right is an endless nightmare. I've been using VisualD for 6 years, and I still can't seem to get the paths right. I'm gonna suggest a new strategy; rather than requiring user configuration, when VisualD can't find a path or tool, or for any other pathing related problem, I think it should present a dialog box prompting the user to find the path to the thing it wants. It should give a message saying what it wants (ie, "where is ldc2.exe?"), and then when the user selects a path, it should write that to the settings. This way, if the user fails to configure paths correctly (seems to be close to 100% of the time, especially on initial installation), rather than getting annoying errors, they will get a prompt to fix it, and it should just work from there on. Sound reasonable?

https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1 has better defaults, but I agree that better guidance in case of errors would be nice. Unfortunately, path issues are not always about Visual D not finding an executable, but the invoked tools need to find DLLs or other stuff (e.g. link.exe needs to find mspdb*.dll and mspdbsrv.exe which needs other DLLs, GDC needs the mingw DLLs). I'm not sure Visual D can cover all possible error situations.

I understand it's not necessarily VD at fault, but I wonder if VisualD can interpret pathing related errors and prompt such that it can set the PATH env var prior to retrying the build again with the new setting? The problem is a symptom of Windows being such a ridiculous and broken platform that nothing lives in predictable locations. VS itself is a special kind of crazy, and sadly, we more-or-less just have to work around it :/

Thinking on it, maybe a better solution would be to remove those settings from the user entirely. Imagine a UI that looks something like: "Add toolchain", the user is then prompted to locate the root directory of the toolchain they want to 'add'. VisualD may then identify if the path appears to be a DMD/LDC/GDC toolchain based on various indicators. It may then even like to invoke the compiler's diagnostic to interrogate the platform(/s) it targets (ie, MSVC/MinGW/ARM/...) I've seen QtCreator and CodeLite work this way, and it is very convenient and easy for users. CodeLite will even do a quick scan of predictable locations for various toolchains that will be configured and made available automatically. Sounds like quite a bit of work, but it might make this entire class of problem disappear once and for all :)

> Sounds like quite a bit of work, but it might make this entire class of problem disappear once and for all :) Although it sounds like a feasible idea I'm a bit hesitent to build a framework for specifying a new tool chain. Each one has its special cases not easily mapped to a simple definition file. It also means that a project won't compile correctly on another system without also transferring the tool chain setup (which is not part of the project). I'll have a closer look at how QtCreator is dealing with this... I was also considering allowing to build through msbuild, but that needs people to write support assemblies for the specific tool chains.

(In reply to Rainer Schuetze from comment #4) > > Sounds like quite a bit of work, but it might make this entire class of problem disappear once and for all :) > > Although it sounds like a feasible idea I'm a bit hesitent to build a > framework for specifying a new tool chain. Each one has its special cases > not easily mapped to a simple definition file. > It also means that a project won't compile correctly on another system > without also transferring the tool chain setup (which is not part of the > project). This is an open problem. A project with an 'XBox 360' platform can't build those configurations if the user doesn't have the toolset installed. In the case of C/C++, if the platform is unavailable, the project still loads, but those particular configurations give build errors. I think the conventional way to solve this problem is to make the solution platforms known defined values. That way, when the user configures the toolchain, the solution platform names will be standardised and match properly. Clang support is implemented via platform-toolset, but the same story there; platform toolset names need to match appropriately, although in that case, it's all just MSBuild mischief. If LLVM isn't installed, it just complains when trying to build that config. > I'll have a closer look at how QtCreator is dealing with this... > > I was also considering allowing to build through msbuild, but that needs > people to write support assemblies for the specific tool chains. I had a brief look into this at one point; it looked to me like it might be possible to make regular vcxproj files capable of building D code with appropriate property pages. The problem then would probably become launching the correct debug environment when launching.

Installation paths are now verified by showing the compiler version since https://github.com/dlang/visuald/releases/tag/v0.48.0-beta1. Also the discussed msbuild project integration is up and running for some time.