On Sun, 13 Feb 2011 08:00:57 +0200, golgeliyele <usul...@gmail.com> wrote:
The error reporting has issues as well. I noticed that the compiler
leaks low level errors to the user. If you forget to add a main to your
app or misspell it, you get errors like:
====
Undefined symbols:
"__Dmain", referenced from:
_D2rt6dmain24mainUiPPaZi7runMainMFZv in
libphobos2.a(dmain2_513_1a5.o)
====
I mean, wow, this should really be handled better.
This has been brought up before. Walter insists it's not a problem.
Another annoyance, for me anyway, is that the DMD compiler outputs the
.o files without the package directory hierarchy. I like to
organize my code as 'src/my/package/module.d'. And I want to set my
output directory to 'lib' and get 'lib/my/package/module.o'.
But DMD generates 'lib/module.o'. I setup my project to build each .d
file into a .o file as a separate step. I don't even know if this is
the desired setup. But that seems to be the way to make it incremental.
I couldn't find any definitive information on this in the DMD
compiler web page. It says:
"dmd can build an executable much faster if as many of the source files
as possible are put on the command line.
Correctly-working incremental builds are not possible with DMD. This is an
old problem that isn't easy to fix, due to the way the compiler was
designed and written.
Another advantage to putting multiple source files on the same
invocation of dmd is that dmd will be able to do some level of cross-
module optimizations, such as function inlining across modules."
I've been told that DMD will actually do cross-module optimizations even
if you don't specify the other modules on its command-line. Unless you use
.di files, the point is that unlike C++, the compiler has access to the
full source code of all included modules, not just a header file, so it
can do inlining and whatnot.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
