Are there any FOSS tools for doing dependency analysis of (e.g.) all the d files in a directory, to let you know when a .o file needs to be regenerated?

This presumably would depend mostly on the import statements (including import of any file to be used in string construction, as in 'auto my_string = import("my_file");').

My guess is there must be, because one of the big deals about d is the more regular syntax it offers to make compiler building more reliable.

(I'm using gdc, and building with gnumake.)

TIA for any info!

dan

On 09/04/2016 12:07 AM, dan wrote:
> Are there any FOSS tools for doing dependency analysis of (e.g.) all the
> d files in a directory, to let you know when a .o file needs to be
> regenerated?
>
> This presumably would depend mostly on the import statements (including
> import of any file to be used in string construction, as in 'auto
> my_string = import("my_file");').

dmd itself has two related switches:

* -deps prints out imports and such.
* -v prints out the same information in different format, and also a lot more other stuff, including which dmd binary is being used and the config file.

rdmd uses -v to figure out the dependencies of the root module. Here's how it parses the output:
https://github.com/dlang/tools/blob/master/rdmd.d#L643-L691

I'm not aware of a standalone tool that does something like this. If you want to write one, you could do like rdmd and use `dmd -deps`/`dmd -v`, or you could use a standalone D parser like libdparse.

http://code.dlang.org/packages/libdparse

[...]
> (I'm using gdc, and building with gnumake.)

I'm not sure how similar or different gdc is to dmd with regards to the -deps/-v switches. A quick test suggests that gdc has a --deps switch that behaves like dmd's -deps. It seems to be undocumented. The output of gdc's -v does apparently not include the imports, though.

On Monday, 5 September 2016 at 18:22:08 UTC, ag0aep6g wrote:
> On 09/04/2016 12:07 AM, dan wrote:
>> Are there any FOSS tools for doing dependency analysis of [...]
> [...]
> I'm not aware of a standalone tool that does something like this. If you want to write one, you could do like rdmd and use `dmd -deps`/`dmd -v`, or you could use a standalone D parser like libdparse.
>
> http://code.dlang.org/packages/libdparse

I have one in dastworx, based on dparse:

https://github.com/BBasile/Coedit/blob/master/dastworx/src/imports.d#L64

It would be very easy to make it a standalone tool (dastworx is a standalone tool but its main() is specific to Coedit) or to add such an anlayzer to Dscanner.

about 200 SLOCs not more.

On Monday, 5 September 2016 at 18:49:25 UTC, Basile B. wrote:
> On Monday, 5 September 2016 at 18:22:08 UTC, ag0aep6g wrote:
>> On 09/04/2016 12:07 AM, dan wrote:
>>> Are there any FOSS tools for doing dependency analysis of [...]
>> [...]
>> I'm not aware of a standalone tool that does something like this. If you want to write one, you could do like rdmd and use `dmd -deps`/`dmd -v`, or you could use a standalone D parser like libdparse.
>>
>> http://code.dlang.org/packages/libdparse
>
> I have one in dastworx, based on dparse:
>
> https://github.com/BBasile/Coedit/blob/master/dastworx/src/imports.d#L64
>

Thanks Basile and also ag0aep6g for your replies, which give me several things to try.

dan

On Monday, 5 September 2016 at 18:49:25 UTC, Basile B. wrote:
> On Monday, 5 September 2016 at 18:22:08 UTC, ag0aep6g wrote:
>> On 09/04/2016 12:07 AM, dan wrote:
>>> Are there any FOSS tools for doing dependency analysis of [...]
>> [...]
>> I'm not aware of a standalone tool that does something like this. If you want to write one, you could do like rdmd and use `dmd -deps`/`dmd -v`, or you could use a standalone D parser like libdparse.
>>
>> http://code.dlang.org/packages/libdparse
>
> I have one in dastworx, based on dparse:
>
> https://github.com/BBasile/Coedit/blob/master/dastworx/src/imports.d#L64
>
> It would be very easy to make it a standalone tool (dastworx is a standalone tool but its main() is specific to Coedit) or to add such an anlayzer to Dscanner.
>
> about 200 SLOCs not more.

Oops, big mouth syndrome here, it would be actually more complex because a persistent associative array is needed to link filenames to modules, projects to filename, date stamps to filename, etc...Otherwise at each execution there are a lot of stuff to parse. dastworx does not implement these features because they are done in an IDE module (the "libman").