resurrecting Bud and Rebuild

Walter Bright newshound at digitalmars.com
Wed Feb 7 15:56:27 PST 2007


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


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



More information about the Digitalmars-d mailing list