I don't use Visual D myself, but I'm trying to put together a newbie's guide to set up D and hack on some of my code / libraries.

My question is: is it possible to use source libraries (i.e. just a bunch of .d modules that don't build to a .lib file) with Visual D, without having to add the entire library to the project?

Normally, I use a build tool (bud/rebuild/xfbuild/rdmd) to build my D code. You only need to pass the name of the main module to the build tool, as it will scan the source files or use dmd's -deps option to obtain a list of modules that need to be compiled and linked. This way, there is no need to specify/maintain a list of modules anywhere but the imports in the source code.

Is there any way to do this in Visual D? If not, is it possible to use Visual D together with a build tool?

Though I have not tried that particular use case, you chould be able to configure a custom rule on your single file. Choose "Properties" from the context menu of the source file in the Solution Explorer and select "Custom" in "Common Properties"->"File"->"Build Tool".

Thanks... I guess I'll wait for the next DMD release with rdmd pull request 14 integrated (otherwise I can't make it play with VisualD's cv2pdb and debugger). Having an interactive debugger is certainly worth additional setup work, but up to a limit, so for now I went with Geany.

Some things I noticed along the way:

1) The file property dialog makes no hint of the macros available there. A link to the documentation could make it more accessible.
2) I noticed Visual D highlights token strings (q{...}) as string literals. I believe the very reason they were introduced was to allow text editors to highlight some string literals as D code, so parsing them as simple string literals defeats their point.

1) The file property dialog makes no hint of the macros available there. A link to the documentation could make it more accessible.

I agree. The macros can be useful in a lot of settings, so the info should be available almost anywhere in the configuration dialog. I'm not sure how to get this with also not taking too much space.

Quote:

2) I noticed Visual D highlights token strings (q{...}) as string literals. I believe the very reason they were introduced was to allow text editors to highlight some string literals as D code, so parsing them as simple string literals defeats their point.

Tokenized string literals have their own set of colors, which is slightly more red than the usual colors, but still different between token types. You can configure them in the Fonts and Color options dialog (search for "Visual D Token String...".

Tokenized string literals have their own set of colors, which is slightly more red than the usual colors, but still different between token types. You can configure them in the Fonts and Color options dialog (search for "Visual D Token String...".

You're right, sorry... I got fooled by that punctuation has the same color as identifiers and numeric literals.

Decided to give Visual D another try, but didn't get very far - maybe there's something I missed, or at the very least I hope you'll find my feedback useful.

I didn't find any way to add a directory tree at once to a project. Thus, as far as I can tell, there's no way to create a Visual D project out of an existing source tree, other than manually recreating the directory structure by adding the files from each individual directory, one by one. If there was a way to add a source tree to an empty D project, I could have provided instructions to exclude conflicting or unneeded modules.

Combining this with my above posts, here's an idea for a Visual D feature: A "New Project" wizard, which allows the user to specify the main file of a D program. Visual D would then run dmd -deps to get a list of files to include in the project.

Did you try to drag the source folder from the explorer into an existing project in the solution explorer? This reconstructs the full file and directory tree in the project.

Having a template to create a Visual D project from an existing source tree sounds like a good idea. That is also annoying with C/C++ projects, because the project wizard always tries to create new directories.

Did you try to drag the source folder from the explorer into an existing project in the solution explorer? This reconstructs the full file and directory tree in the project.

I didn't think to try this. It worked, thanks - but it looks like I underestimated the amount of work needed to cherry-pick which files need to be included in the build. I was reminded today that the -of option works with rdmd, so I may try making something of it tomorrow.

Having played with rdmd's -of option and Visual D, I return with more feedback.

The first thing I tried was to set up a custom build tool for the only .d file in the project. I have indicated that the custom build command will create the $(TARGETPATH), however even though the build command succeeded, Visual D didn't take the hint and still attempted to link the file manually (due to cv2pdb, perhaps?).

When there are no D files in the project for Visual D to compile (i.e. the only one has a custom build command), and the project's compilation mode is set to either "Combined compile and link" or "Single file compilation", Visual D aborts the build with a "no object files to link" error. However, in the same situation but with the compilation mode set to either "Separate compile and link" or "Compile only", Visual D attempts to run DMD with no D files on its command line. As a result, DMD prints out its usage help text and Visual D considers the build failed.

A hack I found to work to some degree was to write a dummy program which does nothing, and indicate that program's executable as the DMD compiler for Visual D to use. Basic building works, but there's no automatic dependency tracking this way (editing another file in the project doesn't trigger a rebuild - one would need to specify all dependencies manually). I didn't go much further, but I guess that cv2pdb would need to be set up as a manual post-build command as well.

I've discovered a bug in rdmd's handling of the -of option: it will add a .exe extension even if one is already specified. This makes it impossible to make rdmd output a file with the .exe_cv extension with a single command. I've included the fix as part of this pull request.

I think that adding support for using rdmd as a compilation model to Visual D would have measurable benefits. It would allow using Visual D's UI to set various compilation flags, while making use of rdmd's dependency tracking. rdmd is now a standard part of the DMD distribution - the only remaining question is how to allow the user to specify the "main" file in the project which should be passed to rdmd.

I think what can work is to use the d-file as usual, but specify rdmd as the "other compiler" in the project configuration. In addition, specify "--build-only" as an additional command line options.

I just tried it, and it seems to work but for the wrong exe file name and the fact that rdmd does not parse the -map option correctly. (Until only very recently dmd used to always write a map file, so Visual D always uses the -map options to get it out of the source folder.)

If you select "Mago" as the debug engine, no extra conversion step is necessary, but rdmd still adds another ".exe".

rdmd is ok to simply run a file from the command line like scripts, but I'm not sure it is that useful in an IDE:
- you usually want to see the files that you are working on
- it does not scale well, because when working with multiple projects that generate static libraries and are linked together in the last step, you will probably end up with lots of multiple definitions.

I think what can work is to use the d-file as usual, but specify rdmd as the "other compiler" in the project configuration. In addition, specify "--build-only" as an additional command line options.

I just tried it, and it seems to work but for the wrong exe file name and the fact that rdmd does not parse the -map option correctly. (Until only very recently dmd used to always write a map file, so Visual D always uses the -map options to get it out of the source folder.)

Thanks, I got it working with two more fixes in rdmd's argument handling.

Quote:

rdmd is ok to simply run a file from the command line like scripts, but I'm not sure it is that useful in an IDE:
- you usually want to see the files that you are working on
- it does not scale well, because when working with multiple projects that generate static libraries and are linked together in the last step, you will probably end up with lots of multiple definitions.

I was not suggesting for Visual D to adopt rdmd as the sole building method. I tried explaining in this thread why Visual D is currently not practically usable without careful configuration for cases like mine. This is your project and I respect your opinion, I just hoped you would find my feedback helpful to make Visual D useful for a larger audience.

Doesn't Visual D collect dependency information already? Perhaps it was silly of me to suggest depending on a build tool when Visual D could easily do the same task itself.

I was not suggesting for Visual D to adopt rdmd as the sole building method. I tried explaining in this thread why Visual D is currently not practically usable without careful configuration for cases like mine. This is your project and I respect your opinion, I just hoped you would find my feedback helpful to make Visual D useful for a larger audience.

Your feedback is very welcome, thanks for that. I had no intention to sound dismissive I have placed some of your issues on my todo list.

Quote:

Doesn't Visual D collect dependency information already? Perhaps it was silly of me to suggest depending on a build tool when Visual D could easily do the same task itself.