tooling quality and some random rant

Walter Bright newshound2 at digitalmars.com
Sun Feb 13 11:30:06 PST 2011


gölgeliyele wrote:
> Walter Bright <newshound2 at 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 :)

I find that people have all kinds of ways they wish to use a compiler. Is it 
worth restricting all that just for the case of one error message?

I also have tried to avoid adding endless command line switches as the solution 
to every variation people want. These cause:

1. people just check out when they see pages and pages of wacky switches. Has 
anyone ever actually read all of man gcc?

2. different compiler switches can have unexpected interactions and 
complications when used together. This is impossible to test for, as the 
combinations increase as the factorial of the number of switches.

3. people tend to copy/paste makefiles from one project to the next. They 
copy/paste the switches, too, usually with no idea what those switches do. I.e. 
they treat those switches as some sort of sacred incantation that they dare not 
change.


More information about the Digitalmars-d mailing list