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