On Mon, 10 Nov 2014 13:29:02 +0000
Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> The problem that I'm having with this seems to be with GDC, not the rest of the D community. The following is a quote of the entire amount of information in the GDC man page on the following compiler options and file extensions:
> 
> SYNOPSIS
>          gdc [-c]
>              [-g] [-pg] [-Olevel]
>              [-Idir...] [-Ldir...]
>              [-o outfile] infile...
> 
>          For any given input file, the file name suffix determines
> what kind of
>          compilation is done:
> 
>          file.d
>              D source files.
> 
>          file.di
>              D interface files.
> 
>          file.o
>              Object files to link in.
> 
>          file.a
>              Library files to link in
> 
> 
> So I could *guess* that a dot o file is the equivalent of a .obj file an Windows, and *guess* that a dot a file is the equivalent of a .lib file on Windows, then follow some Windows instructions as on the page http://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows but I would totally be guessing, and I still wouldn't know where to get any .a files, but I could *guess* that I would get a .o file by running the compiler and naming the output a .o file by using the -o switch. I would be totally guessing, and if I'm wrong, all my builds would be wrong and incompatible with other people's build systems.

you'd better use some IDE if you have to guess such things. gdc manpage documents gdc-specific options. it even gives you some directions in "see also" section, which you are supposed to follow to read more about GCC suite. GCC also has extensive on-line documentation.

yes, you are supposed to know how to use GCC, part of which gdc is. if you don't want to think about that, you can use IDE which does all this for you automatically.

On Monday, 10 November 2014 at 13:44:26 UTC, ketmar via
Digitalmars-d-learn wrote:

> you'd better use some IDE if you have to guess such things. gdc manpage
> documents gdc-specific options. it even gives you some directions in
> "see also" section, which you are supposed to follow to read more about
> GCC suite. GCC also has extensive on-line documentation.
>
> yes, you are supposed to know how to use GCC, part of which gdc is. if
> you don't want to think about that, you can use IDE which does all this
> for you automatically.

I keep saying I want documentation or specifications. If there
isn't any, how would the people who write the IDE frontends for
languages know whether they're doing it right? Maybe they aren't
and they're just guessing and naming output files whatever way
sounds and looks right to them, so it sort of fits with what
output people expect, without actually being the right format of
files!

(I quoted from the GDC man page. How do you think I did that if
it wasn't for reading it?)

Some pages say to rename output files with ".a" if you want a
library type file, other pages say they're an archive format for
library files. So this isn't idle speculation that there might be
some confusion by tool writers or there might be a lack of enough
officially specified standards or accessible enough documentation.

http://rainers.github.io/visuald/visuald/Installation.html
quote
when building a library you should change the output file name
extension to ".a".
end quote

On Mon, 10 Nov 2014 14:12:12 +0000
Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> I keep saying I want documentation or specifications.
and i keep saying that if you can't find those for you case, you'd better stick with IDE. you keep ignoring the fact that gdc is a part of GCC and you have to read GCC documentation to understand the process.

ok, it's your right to insist that gdc must include GCC documentation, but don't expect it to happen, as this will be a useless duplication.

any person that is familiar with GCC suite immediately groks how to use gdc, 'cause it's not different from other GCC frontends. sure, it has some specific options, and those options are documented in manpage.

if you don't want to see gdc as a part of GCC suite... oh, well, it's your choice. other gdc users has no problems with that and they aren't refusing to understand how GCC should be used, what files it produces and how.

as you obviously don't want to learn that, i keep recommending you to use IDE for working with your code, 'cause IDE knows how to call requred tools from the toolchain.

On Monday, 10 November 2014 at 12:10:37 UTC, Solomon E wrote:
> I don't trust the
> DMD Debian package enough to install it, considering it has
> Google adsense ads in its HTML pages, which is against even
> Google's policy.

Could you point to the exact page your looking at?

On Monday, 10 November 2014 at 15:35:54 UTC, ketmar via
Digitalmars-d-learn wrote:
> On Mon, 10 Nov 2014 14:12:12 +0000
> Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
>
>> I keep saying I want documentation or specifications.
> and i keep saying that if you can't find those for you case, you'd
> better stick with IDE. you keep ignoring the fact that gdc is a part of
> GCC and you have to read GCC documentation to understand the process.
>
> ok, it's your right to insist that gdc must include GCC documentation,
> but don't expect it to happen, as this will be a useless duplication.
>
> any person that is familiar with GCC suite immediately groks how to use
> gdc, 'cause it's not different from other GCC frontends. sure, it has
> some specific options, and those options are documented in manpage.
>
> if you don't want to see gdc as a part of GCC suite... oh, well, it's
> your choice. other gdc users has no problems with that and they aren't
> refusing to understand how GCC should be used, what files it produces
> and how.
>
> as you obviously don't want to learn that, i keep recommending you to
> use IDE for working with your code, 'cause IDE knows how to call
> requred tools from the toolchain.

I do know about how to use GCC and where the documentation for
that is. I know what .o files and .a files are in terms of GCC
for C, because there's tons of documentation about that. I
thought that there might be a little bit of documentation about
what they are for D, or a specification. A language that's about
"grokking" things (I've read Stranger in a Strange Land, so I
"grok" what it means) is not the sort of language that I want to
use. I prefer that a language that specifies what a computer is
to do be specified itself. That is all.

I don't want to use an IDE that pretends to have AI about what to
do for me, just because a language doesn't have enough
documentation to let me know what to do for myself. That's like
the opposite of learning to program. In this case it's about the
tiny amount of documentation for GDC, which assumes that users
will know about using GCC for C or C++ and will apply a diff of
how D differs from those to use it for D. 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++ and not as a language in
its own right, with examples that may or may not be complete and
who can tell where they are complete enough and where they aren't?

On Monday, 10 November 2014 at 16:49:27 UTC, John Colvin wrote:
> On Monday, 10 November 2014 at 12:10:37 UTC, Solomon E wrote:
>> I don't trust the
>> DMD Debian package enough to install it, considering it has
>> Google adsense ads in its HTML pages, which is against even
>> Google's policy.
>
> Could you point to the exact page your looking at?

Gdebi Package Installer gave privacy-breach-google-adsense as a
Lintian output for about a hundred pages in
dmd_2.066.0-0_amd64.deb (as well as a lot of other problems I
don't know about.)

https://lintian.debian.org/tags/privacy-breach-google-adsense.html

I tried extracting the pages in question and viewing them, and
yes, they do serve Google ads from online while browsing local
html files.

On Mon, 10 Nov 2014 17:18:05 +0000
Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> I do know about how to use GCC and where the documentation for that is. I know what .o files and .a files are in terms of GCC for C, because there's tons of documentation about that. I thought that there might be a little bit of documentation about what they are for D, or a specification.
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.

> A language that's about
> "grokking" things (I've read Stranger in a Strange Land, so I
> "grok" what it means) is not the sort of language that I want to
> use. I prefer that a language that specifies what a computer is
> to do be specified itself. That is all.
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 don't want to use an IDE that pretends to have AI about what to do for me, just because a language doesn't have enough documentation to let me know what to do for myself.
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.

> In this case it's about the
> tiny amount of documentation for GDC, which assumes that users
> will know about using GCC for C or C++ and will apply a diff of
> how D differs from those to use it for D.
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.

On Mon, 10 Nov 2014 16:49:26 +0000
John Colvin via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Monday, 10 November 2014 at 12:10:37 UTC, Solomon E wrote:
> > I don't trust the
> > DMD Debian package enough to install it, considering it has
> > Google adsense ads in its HTML pages, which is against even
> > Google's policy.
> 
> Could you point to the exact page your looking at?
i remember that there was commit that removes adsense from default documentation pages. that was left by accident and nobody pays attention to it, partially due to adblockers, and partially due to using dlang.org for reading documentation.

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.

On Mon, 10 Nov 2014 21:27:20 +0000
Solomon E via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> (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.
you've been told several times that gdc is a part of GCC suite. there are extensive documentation and howtos for GCC. you are expected to read and understand that. there is nothing special in gdc which renders GCC documentation unusable for it. yet you keep ignoring that and insisting that GCC documentation should be duplicated for gdc. GCC is "GNU Complier Collection", thus it means that GCC compilers have similar interfaces. you can also read about ABI in GCC documentation to discover the extents to which object files from one language are compatible with object files from another language. you are also expected to read binutils documentation to learn what .a files for, how they are created and used. there is no point to duplicate this information for each part of the suite.

if you are insisting on using command-line tools, you are expected to be expirienced enough. and if you don't want to learn how to use them, you are free to use some IDE, which will do most of the dirty work for you.

so the answer is no, there aren't any copies of GCC and binutils documentation in gdc. they aren't required.