On Tue, 18 Jan 2011 13:28:32 +0200, Walter Bright
<newshou...@digitalmars.com> wrote:
What is that message?
C:\Temp\D\Build> dmd test1.d
OPTLINK (R) for Win32 Release 8.00.8
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test1.obj(test1)
Error 42: Symbol Undefined _D5test21fFZv
--- errorlevel 1
1) The error message is very technical:
a) does not indicate what exactly is wrong (module not passed to
linker, not that the linker knows that)
There could be many reasons for the error, see:
Sorry, you're missing the point. The toolchain has the ability to output a
much more helpful error message (or just do the right thing and compile
the whole project, which is obviously what the user intends to do in 99%
of the time).
http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined
which is linked from the url listed:
http://www.digitalmars.com/ctg/optlink.html
and more directly from the FAQ:
http://www.digitalmars.com/faq.html
b) does not give any indication of what the user has to do to fix it
The link above does give such suggestions, depending on what the cause
of the error is.
This is not nearly good enough. I can bet you that over 95% of users will
Google for the error message instead. Further more, that webpage is very
technical. Some D users (those wanting a high-performance high-level
programming language) don't even need to know what a linker is or does.
2) OPTLINK doesn't demangle D mangled names, when it could, and it
would improve the readability of its error messages considerably.
(I know not all mangled names are demangleable, but it'd be a great
improvement regardless)
The odd thing is that Optlink did demangle the C++ mangled names, and
people actually didn't like it that much.
I think we can agree that there is a significant difference between the
two audiences (users of your C++ toolchain who need a high-end,
high-performance C++ compiler, vs. people who want to try a new
programming language). You can make it an option, or just print both
mangled and demangled.
dmd can build entire programs with one command:
dmd file1.d file2.d file3.d ...etc...
That doesn't scale anywhere. What if you want to use a 3rd-party
library with a few dozen modules?
Just type the filenames and library names on the command line. You can
put hundreds if you like. If you do blow up the command line processor
(nothing dmd can do about that), you can put all those files in a file,
say "cmd", and invoke with:
dmd @cmd
The only limit is the amount of memory in your system.
That's not what I meant - I meant it doesn't scale as far as user effort
in concerned. There is no reason why D should force users to maintain
response files, make files, etc. D (the language) doesn't need them, and
nor should the reference implementation.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
