On Thursday, 24 August 2017 at 17:37:12 UTC, Jonathan Marler
wrote:
On Thursday, 24 August 2017 at 16:49:08 UTC, Seb wrote:
On Thursday, 24 August 2017 at 16:32:32 UTC, Jonathan Marler
wrote:
On Thursday, 24 August 2017 at 15:56:32 UTC, H. S. Teoh wrote:
On Thu, Aug 24, 2017 at 03:53:05PM +0000, Jonathan Marler
via Digitalmars-d wrote:
Wanted to get peoples thoughts on this. The idea is to
have a way to tell the compiler (probably with a command
line option) that you'd like to "compile imported modules".
[...]
Isn't this what rdmd already does?
T
That is one thing that rdmd does (as I mentioned in the
original post).
I just looked through the rdmd code
(https://github.com/dlang/tools/blob/master/rdmd.d) and it
looks like it invokes the compiler using "dmd -v" to get the
list of modules and then invokes the compiler again with the
modules it found to perform the full compile. So my original
thought that the logic to find modules is duplicated was
incorrect. Instead we just pay a performance hit to get the
correct list of imports since running "dmd -v" seems to take
almost as long as the actual compile itself. So this method
comes close to doubling the time it takes to compile than if
the feature was implemented in the compiler itself.
In any case, the idea is to allow the compiler to resolve
this on it's own without help from rdmd. This would remove
the need to invoke the compiler twice, once to find the
imports and once to compile. It would also allow some
projects/applications that don't use rdmd to take advantage
of this feature, this may or may not include dub (not sure on
that one).
rdmd is really bad in terms of performance. If you call a
single D file with rdmd, it will always compile it twice.
There was an attempt to fix this
(https://github.com/dlang/tools/pull/194), but this has been
reverted as it introduced a regression and no one had time to
look at the regression.
Moving rdmd into DMD has been on the TODO list for quite a
while and there is a consensus that the performance overhead
if rdmd isn't nice. However, IIRC there was no clear consensus
on how the integration should happen. I recall that the plan
was to do try this with "dmd as a library", but I'm not sure
whether that's really feasible ATM.
Well this should solve the rdmd performance problem as well as
make other user cases easier that don't necessarilly use rdmd.
I had another thought that instead of making this an "opt-in"
feature, it would probably make more sense to be an "opt-out"
feature. So by default the compiler would compile missing
imported modules unless you indicate otherwise, maybe a command
line switch like "-dont-compile-imports". And I don't see how
this would break anything. Everything should work the same as
it did before, it's just now you can omit imported module files
from the command line and it should just work.
I've looked through the DMD code to see how this could be
implemented and I've run into a problem. The solution I came up
with was to go through all the imported modules and then
determine which ones need to be compiled that haven't been given
on the command line. The problem is, I don't know how to
determine whether a module was already compiled and given in an
obj/lib file. For example,
dmd something.obj anotherthing.lib prog.d
As far as I know, the compiler has no idea which modules are
contained in "something.obj" and "anotherthing.lib". It just
compiles the source given on then command line, then passes all
the object files and libraries to the linker, at which point the
concept of modules is lost.
Am I correct in saying that the compiler has no idea which
modules an obj/lib file contains?
