I wonder if we can get something positive out of this discussion. I would like to enumerate a few possibilities for the several things we discussed:
1. Difficult to understand linker errors due to missing main(): Fixing this would be useful for newbies. If there is not already a defect on this, I suggest we file a defect and it gets fixed sometime. I am assuming that this can be caught before going to the linker. Does dmd support creating an executable whose main() comes from a library? If not, the compiler would know if there is a main() or not before doing the linking. I can see how this is a problem with incremental builds though. However, with the compilation model that is being advocated by the documentation (i.e, feed dmd all the .d files at once), the compiler should know if main() is there or not. Yet another reason to clarify the compilation model, IMO. 2. dmd compiler's command line options: This is mostly an esthetic issue. However, it is like the entrance to your house. People who are not sure about entering in care about what it looks like from the outside. If Walter is willing, I can work on a command line options interface proposal that would keep backwards compatibility with the existing options. This would enable a staged transition. Would there be an interest in this? 3. Incremental compilation (or lack of it) First of all there is a documentation problem here. There needs to be clarity about whether incremental compilation is possible or not. I won't count approaches that work partially as anything more than a stopgap solution. IMO, it is acceptable if we can state that dmd compilations are blazingly fast, and as a result, there is no reason to do incremental compilation. The problem is that I get mixed signals on this point: - If this claim is true, then I think it should be asserted strongly and should be backed up by numbers (100K library compilation takes X seconds, etc.) - If this claim is false, then we should look at enhancing the tooling with things like xfBuild. Perhaps that kind of functionality can be built into the compiler itself. Whatever is needed, the following needs to be clearly documented: What is the best way to organize the build of large projects? It is a mistake to consider the language without the tooling that goes along with it. I think there is still time to recover from this error. Large projects are often build as a series of libraries. When the shared library problem is to be attacked, I think the tooling needs to be part of that design. Solving the tooling problem will raise D to one level up and I hope the community will step up to the challenge. One last thing: Personally, I don't like this business with .di files. They are optional, but then they are needed for certain use cases. I believe the information that is contained in .di files should be packed alongside the shared library and I should be able to build/link against a single library package. I haven't used Java for a long time, but I recall you get a .jar file and javadoc documentation when you are handed a library. I like that. p.s.: Does anyone know what the best way to use this newsgroup is? Is there a better web interface? If not, is there a free newsgroup (on a Mac) reader that is easy to use?
