Instructions for compilation from multiple source files

[Solomon E via Digitalmars-d-learn]

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.