resurrecting Bud and Rebuild

[Gregor Richards]

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).

I think we're talking about slightly different scenarios. If it simply 
mixes in the file, then this would work perfectly. So would the below if 
it listed files that were imported with import(filename)

But, if it mixes in "import <module name>;", then I'll need not only to 
compile a.d, but whatever module is imported via mixin("import").  To 
compile this next module, the feature I listed below would be necessary.


> 
> 
>> 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.

Fantastic :)

  - Gregor Richards