Speed up compilation in Visual D

[Rainer Schuetze]

On 26/04/2019 06:50, Alex wrote:
>>
>> You might want to try "single file compilation" with "keep path from
>> source" instead.
>>
> When I try single file compilation I get errors about models not being
> found. the problem doesn't exist in combined compilation.
> 
> I think, but not sure, it's because I have some files in different
> directories that access files across "realms".
>> So I'm having to add include's for all these directories just to get
> things to compile ;/
> 
> Since I use a hierarchy of folders, this is a real pain in the ass ;/ D
> doesn't seem to let one recursively search included subdirectories for
> the includes ;/
> 
> It wants a flat list of files to work well, it seems, which is asinine
> given that it is very hard to maintain projects that way.
> 
> Why it works on combined compile I don't know. The build log is vastly
> different and seems to be figuring out the import paths and doing
> something with rsp files.

If the modules are passed on the command line, the compiler already
knows about them by the module statements and doesn't have to search any
directories.

> 
> I won't be able to use single file compilation the way it is working
> since I'd have to include about 100 directories ;/
> 
> ....
> 
> Ok, so I went ahead and did it, it wasn't 100 but about 20. The copy
> full path came in handy.
> 
> Now I get a compiler crash!
> 
> It seems because it is due to the fact that I have some code that reads
> modules and imports their text, which requires a -J for every directory,
> and I have to add it for every new file path I end up using(One thing I
> hate D about because it forces me to keep track of all this mess rather
> than just working).
> 
> The thing is, I have all the proper -J's under command line. But they
> are not showing up on the command line but they are when I do combined
> compile.

You can also add them to the "String import paths" option.

> So possibly this is a bug in Visual D where single compile mode is
> ignoring the additional command line options?

> As if when generating the command line for single file compilation you
> forgot to append the additional options string to it.

Yes, looks like a bug in Visual D: it adds the additional command line
options to the link, but not to the single file compiler invocations.

> 
> 
> 
> May I make a suggestion?
> 
> 
> Allow visual D to automatically generate paths for the command line by
> using wild cards.
> 
> This might require a special input box like
> 
> -J [                         ] [+]
> 
> Where one can then add paths like one can do with imports, versions, etc
> 
> but one can use wild cards like
> 
> C:\Project\*;C:\WaltersSecureInfoToHack\*
> 
> and visual D will parse all the sub directories and add them manually.
> 
> This will alleviate some major headaches with D's security but it should
> be valid since it's used inside an IDE. (since no one passes around
> visual D project files anyways.
> 
> The same could be done for import paths too.
> 
> It would simply allow me to use one import such as C:\Projects\*. Since
> all ones I added are hard coded, if I ever move things around I have to
> modify all the paths(and remember to do so).

I'm not so sure this is a recommended workflow.

If the modules in the different folders depend on each other, you might
start the module hierarchy a bit further up, e.g. make c:\projects the
root of the package hierarchy. Then only a single import path is needed.

If you have independent packages in your projects folder, you could
create separate projects building static libraries. Enabling "Add import
paths of dependent projects" can automatically add the folders to the
main project (but it might miss string imports ATM). This would also
help the initial problem with only recompiling parts that have changed.

You could also generate the import path options to a response file and
add that to the additional command lines as "@import_options.rsp", but
it needs the bug above to be fixed.