• d-bugmail puremagic.com (39/39) Mar 20 2018 https://issues.dlang.org/show_bug.cgi?id=18641

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=18641

          Issue ID: 18641
           Summary: VisualD - First 5 minutes - Improve experience adding
                    .d files to existing C++ projects
           Product: D
           Version: D2
          Hardware: x86
                OS: Windows
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: visuald
          Assignee: nobody puremagic.com
          Reporter: turkeyman gmail.com

I have a colleague who just tried out D for the first time.
He's a gamedev, so coming from VS, and expects a very high bar for quality.

He offered me some feedback which I think it worth passing on.


I wonder if there's any way we can improve the experience of adding .d files to
an existing C++ project.
Currently it will compile the file as expected, but there will be a flood of
link errors.

There are 2 things the user needs to do: add the link path to find the dlib,
and add the dlib.

These 2 tasks are slightly complicated, and a new user will probably fail: the
libs all have different filenames depending on the architecture, and 32bit has
2 variants, and most users will not know which one to pick, or why.

I'd suggest that at very least, Installing VisualD should amend the global
library search paths for each architecture to include the D lib paths, so at
least the user doesn't need to add the proper lib directory to their project.
Users don't need to add paths to the MSC runtime libs.

Then we only have the user adding the lib, which has awkward filenames... I
wonder if we can make a compile option (and enable it by default) that will
embed a link reference to the proper phobos lib in the object file (like VC++
object files to do their respective CRT).
If D object files have a ref to the proper dlib filename, and the lib paths
were known to msbuild by default, then the user wouldn't need to do anything,
and it would all just work!

Naturally, a reference to a dlib should be omitted in -betterc.

--