resurrecting Bud and Rebuild

[Gregor Richards]

Walter Bright wrote:
> It was (correctly) pointed out that textual import breaks Bud and 
> Rebuild. It's also been pointed out that textual import may be an 
> unexpected vector for security problems.
> 
> Both can be resolved by only allowing textual import if a command 
> switch, say, -Jpath, is given. 'path' gives the location of where to 
> look for the file; and the file will be restricted to being under that 
> path. No -Jpath, and textual import won't be allowed.
> 
> For Bud and Rebuild, if there's no -J, they know there are no textual 
> imports, so they work as before. With -J, they always recompile.

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.


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? :)

  - Gregor Richards