resurrecting Bud and Rebuild

[Frits van Bommel]

Walter Bright wrote:
> Gregor Richards wrote:
>> I can't speak to the security aspect, but I don't think that -J would 
>> be helpful to rebuild. For example, if you have a file a.d:
>>
>> mixin(SomeRidiculouslyComplicatedTemplate!(WithRidiculousArguments));
>>
>>
>> It imports foo/b.d, foo/c.d or foo/d.d depending on some bizarrely 
>> complex situation. Each of them will only work in some scenario.
>>
>> What rebuild sees is just a.d .  -Jpath would suggest that a.d depends 
>> on at least one of foo/b.d, foo/c.d or foo/d.d, but there's no way for 
>> it to know which short of actually resolving the templates.
> 
> That's right, so when it sees -J, it just always rebuilds it (not just 
> if one of its dependencies is newer).

That still doesn't tell it what the dependencies *are*. In the above 
scenario, one of foo/{b,c,d}.d needs to be built & linked as well (as 
well as all modules it depends on, and so on).
Which, I presume, the feature below was requested.

>> The solution? Right now, there's no way to get the list of dependant 
>> files without compiling one. Since rebuild gets meta-data out of 
>> files, it would then have to compile it again, which is why I'm not 
>> doing it that way. I'd like to see something like this:
>>
>> $ [g]dmd -p -files foo.d
>> file foo.d foo
>> file /opt/something/src/phobos/object.d object
>> file /opt/something/src/phobos/std/path.d std.path
>>
>>
>> That way, I could simply run the compiler, and get the list of actual 
>> files (not just imports) from its output. However, the compiler 
>> wouldn't actually compile anything (-p meaning parse-only), and it 
>> would list all the /files/ used (not just the imports).
>>
>>
>> Any way you'd add this feature? :)
> 
> It's a good idea.

Good to hear :)