On 7/23/11 5:34 PM, Vladimir Panteleev wrote:
I was going to suggest something like this, but without creating the
dependency on a 3rd-party build tool. I mentioned in another thread how
DMD shouldn't touch the .di file's mtime. A better idea is to not
attempt to overwrite the file at all if the generated .di is identical
to the old one.
That's a must at any rate, and should be filed as an enhancement
request. The compiler should generate filename.di.tmp, compare it
against filename.di (if any), and then either remove the .tmp if
identical or rename it forcefully to filename.di if different. That's a
classic in code generation tools.
Yes, this is a hack, but it's not the only solution. Aside writing a
build tool, as you mentioned, I believe many organizations include
automatic tests coupled with source control, which could easily detect
check-ins that change .di files.
Yes, neither of the above are "proper" solutions. But, unless I've lost
track of something, you're trying to justify a solid amount of work on
the compiler to implement the "proper" solution, when the above
alternatives are much simpler in practice. (If you have more
counter-arguments, I'd like to hear them.)
I don't think at all these aren't proper. As I said, people are willing
to do crazy things to keep large projects sane. The larger question here
is how to solve a failure scenario, i.e. what can we offer that senior
engineer who fixes the build when the .di files are not in sync anymore.
But wait, there's less. The programmers don't have the option of
grouping method implementations in a hierarchy by functionality (which
is common in visitation patterns - even dmd does so). They must define
one class with everything in one place, and there's no way out of that.
Sorry, I don't understand this part. Could you elaborate?
A class hierarchy defines foo() and bar(). We want to put all foo()
implementations together and all bar() implementations together.
Andrei
