Walter Bright <newshou...@digitalmars.com> wrote: > golgeliyele wrote: >> 1. Difficult to understand linker errors due to missing main(): >> ... > > 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. I would like to question this. Is there a D project where the technique of putting main() into a library has proved useful? I used this in a C++ project of mine, but I have regretted that already. I can imagine having a compiler option to avoid the pre-link check for main(), but I would suggest not even having that. Of course unless we get to know what those complaints you mentioned are :)
>> 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. Thanks for being open. I'll work on this. >> 3. Incremental compilation (or lack of it) >> ... > > 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. I think what we need here is numbers from a project that everyone has access to. What is the largest D project right now? Can we get numbers on that? How much time does it take to compile that project after a change (assuming we are feeding all .d files at once)? >> - If this claim is false, then we should look at enhancing the tooling >> with things like xfBuild. Perhaps that kind of >> ... > > In the worst case, you are no worse off with .di files than with C++ .h files. :) .h files is something I want to forget forever.