On 11/10/2014 9:55 PM, Solomon E wrote:
On Monday, 10 November 2014 at 12:21:51 UTC, bearophile wrote:
That's not applicable because I'm not using DMD. Also that
doesn't answer where a .o or .a file comes from, whether there's
any difference between them besides the name, and if so what.
I've compiled a lot of little examples and tests of D from single
source files, but I haven't seen any .o or .a files yet.
.o and .a have are not a D-specific thing. They are part of the
ecosystem on Posix systems. If you are using C or C++, you would still
be dealing with them. You input source files to a compiler, it creates
object files (.o) and you feed those to a linker to get an executable
binary or an archiver to get a library (.a), which is a collection of
object files that can be linked to an executable.
Please do not confuse this with having anything directly to do with D.
Most of the D compiler implementations on Linux use the GNU compiler
collection (gcc) toolchain to generate binaries, and gcc is a core part
of the Linux ecosystem. If you are working on the command line in Linux,
it's something you have to get your head around eventually. The same
goes for any platform you use.
I was hoping there were instruction pages or documentation pages
on how to compile D projects that have multiple source files.
Assume a directory structure like so:
-project
--source
----main.d
----foo
------bar.d
cd project/source
gdc main.d foo/bar.d -o myapp
No matter which compiler you are using, you have to pass every source
file to it that you want it to compile into the final executable. The
only way around this is to use a build tool like dub or rdmd, which will
hand everything to the compiler for you.
When using gdc, since it is based on gcc then the output for a binary is
always named 'a.out'. The -o option will cause the binary to be named
what ever you set it to, in this case 'myapp'.
Notice that the paths are relative to the currently directory. If main.d
imports foo.bar, then DMD will know do look for foo/bar.d from the
current directory. You can change this up a bit like so:
cd project
gdc -Isource source/main.d source/foo/bar.d -o myapp
Here, the -I option tells dmd to look for imports *in* the source
directory. Now, when it fails when main.d imports foo.bar and the
compiler fails to find the file foo/bar.d relative the the current
directory, it will then look in source/foo/bar.d and find it. That's
only for imports though and not for compilation. When using third-party
libraries, you will usually need to pass the -I switch.
No matter what compiler you use, you can usually run something like gdc
--help to get a list of command line switches and what they do. For dmd,
you can just type 'dmd' to print them.
Since you are using gdc, I suggest you google for tutorials on how to
the gcc tools, particularly compiling. The process in D is basically the
same and the fundamentals of compiling and linking are the same across
compilers. I don't use gdc, but I believe it supports most of the
standard gcc compiler switches and adds some specific ones for D.
Perhaps a page could be added to the Wiki explaining the basics of
compilation with the different compilers, but most of the existing
documentation assumes that users will know at least the basics of using
a compiler from the command line.
Ali Çehreli has put together a fantastic book [1] that is targeted at
beginners. It has a section introducing DMD. That would also be a good
place for you to start. If you understand the fundamentals of one
compiler, you can pick them all up.
[1] http://ddili.org/ders/d.en/index.html
