tooling quality and some random rant

[Walter Bright]

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.