Currently Visual D seems to just do recursive delete for *.obj (and few other files) for output and intermediate paths.

The problem is that the output path is basically also the working directory of my application (which, I believe, is very common in general) and it contains data files that have .obj file ending (in this case wavefront .obj mesh files), which get cleaned as well. Now I have to write protect them so that I can maintain productive edit->compile->test cycle even if I clean the project from time to time.

Would be possible for Visual D to track the files it generates and just delete those, or put the generated .obj (and the rest (not .exe, .lib, .dll etc.)) into separate directory or just reuse the intermediate path?

You could simply add a batch file that copies all the data files after the post build. If the files are large, it would be slow and not work.

Alternatively, you could move pre-build and move back post-build for speed. This, of course, assumes the files are rather static, which they probably are.

Obviously not optimal but might work in your scenario.

On 20.09.2016 20:56, Random D user wrote:
> Currently Visual D seems to just do recursive delete for *.obj (and few
> other files) for output and intermediate paths.
>
> The problem is that the output path is basically also the working
> directory of my application (which, I believe, is very common in
> general) and it contains data files that have .obj file ending (in this
> case wavefront .obj mesh files), which get cleaned as well. Now I have
> to write protect them so that I can maintain productive
> edit->compile->test cycle even if I clean the project from time to time.
>
> Would be possible for Visual D to track the files it generates and just
> delete those, or put the generated .obj (and the rest (not .exe, .lib,
> .dll etc.)) into separate directory or just reuse the intermediate path?

If you use the standard compilation method (combined compile and link) there is usually only one object file generated, so you can specify it explicitly instead of the "*.obj" in the "Files to clean" option.

As the file patterns are appended to both output and intermediate directories to find files to delete, here's a workaround if multiple object files are generated: make the intermediate directory a subdirectory of the output directory (e.g. "$(OutDir)\intermediate") and use "intermediate\*.obj" in the "Files to clean" option.