Instructions for compilation from multiple source files

[Mike Parker via Digitalmars-d-learn]

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