Had another 48hr game jam this weekend...

Brad Anderson eco at gnuk.net
Sun Sep 1 13:29:30 PDT 2013


On Sunday, 1 September 2013 at 20:00:19 UTC, Walter Bright wrote:
> On 9/1/2013 12:38 PM, Andrej Mitrovic wrote:
>> I know you seem to hate automation (because it sometimes 
>> fails), but
>> having each individual person waste hours on initial setup is 
>> much
>> worse than having a script which can potentially fail. At 
>> least the
>> script can be fixed once the bug is reported, and it can be 
>> tested.
>
> Back in the bad old Datalight C days, I relied on the Microsoft 
> linker which came on the DOS system disks. Unfortunately, 
> Microsoft constantly changed it, even with the same version of 
> DOS. Worse, numerous other Microsoft products came with yet 
> other versions of LINK.EXE.
>
> All those linkers behaved differently.
>
> It was a frackin' nightmare to support customers with them. I 
> used to have floppy disks packed full of just different 
> versions of LINK.EXE.
>
> This drove me to get our own linker (BLINK.EXE). While it 
> wasn't perfect, either, at least I could actually fix problems 
> with it rather than throwing up my hands in rage being unable 
> to control the situation.
>
> There's no way we can automate VC 2014 so its unpredictable 
> configuration will work. All we can do is react after the fact.
>
> I don't hate automation. sc.ini works out of the box with the 
> default install of VS 2010.
>
> What I need from you guys and your different VS installs is, 
> for each one, a bug report with what is necessary to get it 
> installed. Then we can add it to the modern version of my 
> floppy disk "linker collection".

This can be automated easily enough.  The installer can detect 
what versions of VS are installed and either set an environment 
variable or modify sc.ini (your choice).  It could probably be 
made forward compatible since Microsoft has been using basically 
the same paths and registry keys for every new release since at 
least VS 2005.  Even if they make a release that the D installer 
doesn't properly detect fixing that is a 5 minute job by one 
person (probably me) versus requiring every user to spend a half 
hour or more (6 hours in Manu's experience) trying to figure out 
how to get 64 bit working.


More information about the Digitalmars-d mailing list