golgeliyele wrote:
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.
The problem is the main() can come from a library, or some other .obj file handed to the compiler that the compiler doesn't look inside. It's a very flexible way to build things, and trying to impose more order on that will surely wind up with complaints from some developers.
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?
A proposal would be nice. But please keep in mind that people often view their build systems / makefiles as black boxes, and breaking them with incompatible changes can be extremely annoying.
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.)
I stopped bothering posting numbers because nobody believed them. I was even once accused of "sabotaging" my own C++ compiler to make dmd look better.
dmc++ is, by far, the fastest C++ compiler available. The people who use it know that and like it a lot. The people who don't use it just assume I'm lying about the speed, and I get tired of being accused of such.
- 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.
In the worst case, you are no worse off with .di files than with C++ .h files.
