Re: Instructions for compilation from multiple source files
Solomon E: I don't want to have to guess how to do it and experiment, as if it's all implementation defined and in flux to the degree that that's the only way to compile anything. It's not in flux. A simple way to compile more than one file is to put them in the same compilation unit (almost the same if you want to create a lib): dmd a.d b.d Otherwise you can also use ddmd and let it find the module dependencies by itself. Bye, bearophile
Re: Instructions for compilation from multiple source files
dmd a.d b.d Otherwise you can also use ddmd and let it find the module dependencies by itself. Am I right understand that if I will put all needed files at src folder and name main file App.d dub will add all needed files to App.d ?
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 12:10:36 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: If there aren't instructions or documentation on how to compile more than one file into a finished D runnable project in a correct way that can grow with larger projects, then I'll have to take it as implied that D is just not ready or not welcoming and I shouldn't use it. you'd better not use command-line toolchain, they all aren't ready. if you can't figure out how to use some compiler of GCC suite, you'd better try some IDEs. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 12:21:51 UTC, bearophile wrote: It's not in flux. A simple way to compile more than one file is to put them in the same compilation unit (almost the same if you want to create a lib): dmd a.d b.d Otherwise you can also use ddmd and let it find the module dependencies by itself. Bye, bearophile 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. I was hoping there were instruction pages or documentation pages on how to compile D projects that have multiple source files.
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 12:49:46 UTC, ketmar via Digitalmars-d-learn wrote: you'd better not use command-line toolchain, they all aren't ready. if you can't figure out how to use some compiler of GCC suite, you'd better try some IDEs. So there's such a lack of documentation on D that I'm *supposed* to just guess and experiment about what .o and .a files might be, or hope that an IDE frontend writer guessed right? There's no specification whatsoever?
Re: Instructions for compilation from multiple source files
On Mon, 2014-11-10 at 12:10 +, Solomon E via Digitalmars-d-learn wrote: I wanted to know how to compile a D program that has multiple source files. I looked under Modules in the language reference, but there isn't anything there about compilation, or anything about where to put the source files, or anything about how the compiler finds the files to use. There are effectively two models of compilation for D codes: 1. Compile each module individually and then link all the object files together. This is the traditional C, C++, Fortran way of working. 2. Compile all module source files all at once. In this mode you can either list all the source files or just the main one and see if the compiler correctly find all the dependencies. For 1 you generally need a build tool. I will, of course (but this is left as an exercise for the reader), suggest using SCons and its magnificent D tool. There is also D support for CMake. I believe Waf has some D support. For Make and any other out of date system, you are on your own! I tend to use SCons for mode 2 as well as I can add extras. I'm currently using the GDC compiler, because 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. If the deb file (or any of the packages) on the D web site have such things then they are broken, and you are quite right, should be ignored. I am using Debian Sid and get my packages from D-Apt, http://d-apt.sourceforge.net/ . This works very well. I looked around the D Wiki for instructions on compilation, and it doesn't seem that there are any instructions other than for DMD on Windows and for compiling a hello world with one source file. The GDC site has no instructions or documentation on how to do compilation. GDC is really just GCC in disguise, and rather usefully compiling D instead of C, C++, Fortran, Ada, Objective-C, etc. So if you have ever used gcc or g++ commands you more or less already know how to use gdc. The GDC man page is the same as the GDC info page. It lists some options for the compiler without listing what they do in the case of D. I'm not getting any .o or .a files out of the compiler, only a.out or whatever file name I choose with the -o option. I don't want to have to guess how to do it and experiment, as if it's all implementation defined and in flux to the degree that that's the only way to compile anything. Actually that is a shame. We should all be prepared to experiment, play (and have fun). I agree there is less documentation than would be good around D generally, but it is a FOSS project without a team of paid staff to work 100% on it. Because volunteers generally prefer to work on code, the documentation tends to get a little left behind. What is needed is for some of the companies using D to give back by in some way funding more work on the documentation. If there aren't instructions or documentation on how to compile more than one file into a finished D runnable project in a correct way that can grow with larger projects, then I'll have to take it as implied that D is just not ready or not welcoming and I shouldn't use it. I think that would be a huge over assumption. D has been ready for use for ages and is in use in many places, just not as many as would be good for D and for native programming in general. I hope you stay with D and discover how welcoming the community is. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Instructions for compilation from multiple source files
On Mon, 2014-11-10 at 13:01 +, Solomon E via Digitalmars-d-learn wrote: On Monday, 10 November 2014 at 12:49:46 UTC, ketmar via Digitalmars-d-learn wrote: you'd better not use command-line toolchain, they all aren't ready. if you can't figure out how to use some compiler of GCC suite, you'd better try some IDEs. So there's such a lack of documentation on D that I'm *supposed* to just guess and experiment about what .o and .a files might be, or hope that an IDE frontend writer guessed right? There's no specification whatsoever? ketmar was just being a teensy weensy bit over-dramatic. He was trying to point out that gdc is part of the GCC and so all the GCC documentation is relevant for gdc. D thus gets huge amounts of documentation for gdc for free. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 13:11:45 UTC, Russel Winder via Digitalmars-d-learn wrote: ketmar was just being a teensy weensy bit over-dramatic. He was trying to point out that gdc is part of the GCC and so all the GCC documentation is relevant for gdc. D thus gets huge amounts of documentation for gdc for free. 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. Again, I was hoping there would be some instruction pages or documentation pages or specifications on this subject.
Re: Instructions for compilation from multiple source files
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
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 13:29:02 + 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. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
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
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 14:12:12 + 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. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
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?
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 15:35:54 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 10 Nov 2014 14:12:12 + 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?
Re: Instructions for compilation from multiple source files
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.
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 17:18:05 + 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. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 16:49:26 + 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. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
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
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 21:27:20 + 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. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
ketmar, I understand that GDC documentation can be as terse as it wants to be, especially in the man page, which is supposed to be the shortest, for quick command line reference. It still seems a little odd to me that there wouldn't be additional instructions somewhere in the introductory pages to D on the D Wiki or somewhere else conveniently linked, on compiling multiple input files that are applicable to GDC or to all three compilers, rather than just specific to DMD on Windows. There's a joke in mathematics that sometimes a hard, unsolved problem is passed over in a paper with the words the rest is left as an exercise for the reader. Leaving the subtleties of multiple file GDC usage as an exercise, whatever those may be for D, if any, is certainly better than omitting language documentation or development or bugfixes, and also better than not having multiple compilers to choose from. So on reflection, I agree with leaving multiple file command line GDC usage as an exercise for anyone who wants to do it, in order to conserve limited development resources for improving more important things about D. So I'm sorry about all the fuss. I would delete the thread if I could. I understand that you're implying multiple file compilation should go smoothly the same for D as it does for any other GCC supported language, without any particular difficulties for D that you've seen about it, and I hope it goes smoothly for me as well.
Re: Instructions for compilation from multiple source files
It all works fine for me so far. I wrote a trivial test project of four d files, and compiled it all together, directly from d files, which took a couple of seconds to compile. Then instead I compiled it as two o files in an a file (using ar to archive), plus a d file, plus another o file for good measure, and that was faster on the final compile time.
