On Monday, 10 November 2014 at 19:09:45 UTC, ketmar via
Digitalmars-d-learn wrote:
as for D... they are compiled object files. exactly the same
thing as
for c++, gnu pascal or any other language in GCC that produces
.o. are
you expecting them to be something special? then you'll read
about that
in gdc manpage.
That's nice. That implies all those "compiled object files" are
compatible regardless of language. I don't know if that's true.
It seems doubtful to me.
how this belongs to particular D compiler? you are *expected* to
understand what is "being part of GCC suite" for GNU D
compiler. it's
not about language at all, it's about toolchain. and this is
not the
only one compiler available, and there inevitably will be more.
do you
expecting to read about every specific compiler implementation
in
language dox? DMD happens to be special one 'cause it's a
"reference
compiler" for D. yet there is nothing special in DMD, it's an
ordinary
command-line compiler. if you know how to use one of them, you
know how
to use all of them.
I thought part of learning D would be learning to compile larger
programs than hello world. So I thought D.learn would be the
correct forum to ask a question about where the documentation or
specifications are for the files types involved in D on Linux, if
any. I disagree that knowing how to use one command line compiler
means knowing how to use all command line compilers. Maybe there
have been a few more command line compilers in computer history
than you're taking account of.
should D documentation include all all POSIX documentation for
core
utils, 'cause some of them can be needed to work with source
files? and
for VIM, and for Emacs and for all other editors, 'cause, ahem,
they
can be used to edit D sources? you are *expected* to know how
your
system works, what "file" and "directory" is, what is
"compiling to
object file", what is "linking" and so on. if there is
something that
deviates from common system way of doing things, only then it is
documented. like gdc-specific command line arguments.
I've run across a similar attitude before. When I tried MinGW and
GCC the first time to use C, there were no instructions on the
whole MinGW site for how to compile even a "hello world" using it
for C, only for C++ instead. When I sent a message about that,
also mentioning that I was somewhat confused by what sort of
shell MinGW produced, what was it exactly, I was told it was bash
and directed to the Beginner's Guide to Bash, which I found I
couldn't use according to that guide's own instructions, because
I wasn't already experienced in installing and running programs
on a Unix-like system, which that guide says is a prerequisite.
(Of course I got going and did what I wanted to do with C anyway.
Those were just some learner's questions, normal for learning a
different computer program with incomplete instructions, I
thought. Apparently some experienced Unix-like system users have
a different attitude.)
It's true, you are expected to know your system, even if it's
brand new to you and the instructions are only for experienced
users and warn you away from using them if you aren't an
experienced user yet. This is a problem. Why not just somewhere
have a few lines of examples and type signatures for the various
elementary commands for a compiler, as part of the documentation
or specification that it's supposed to meet in order to be
considered functional? I'm not asking for that to be in the D
language specifications, because it is about GDC.
it's the easiest way to describe such things. i don't see how
it is
necessary to copy and paste all GCC documentation for gdc.
In other cases I've
seen all over the "Language Reference" it's the same thing: D
is
described roughly as a diff of C and C++
you realised that language reference is not meant for those who
learning how to program, didn't you? there is the excellent
book by Ali
Çehreli which is not "diff" and targeted to those who learning
D, for
example. and then you are expected to read documentation for
GCC if you
are planning to use gdc, as gdc is a part of GCC.
there is nothing unsusual in not finding the information you
want if
you are looking for it in the wrong place. physics textbook
will not
start with teaching you simple math.
I already downloaded and started working through the examples in
that book a couple of weeks ago. The sort of assumption I'm
talking about is here again, that doing the simplest things with
a compiler is like "simple math" in your analogy. If someone has
been using similar compilers for years and years, I suppose it
seems so. People seem to lose sight of the fact that computer
programs allow fully arbitrary interpretation of commands and
their results. So whatever a person guesses about how it works or
reads in a textbook about some other program or a related program
with a similar name or similar commands might not apply to the
program a person wants to use.
In this whole thread, I haven't been asking for personalized help
or advice. I've only been asking whether there are some
instructions, documentation, or specifications for GDC
compilation that cover multiple input files, other than the
extremely limited amount in the man page.
(There is a dlang page http://wiki.dlang.org/GDC/Using_GDC that
gives some instructions, including how to compile hello world and
how to get a .o file, but strangely to me doesn't include any
examples or abstracted formulas of how to use more input files or
any mention of .a files.)
So I guess the answer is, no, there isn't any documentation or
specification that covers it, and not even any official
instructions or beginner's guide that covers it. I wish people
would just be honest and up front about saying, no, sorry, we
don't have that; instead of people always seeming to want to put
down people who ask questions about the essentials.
