On 2 September 2013 06:00, Walter Bright <newshou...@digitalmars.com> 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. > MS always release preview versions to toolchain/workflow vendors though. You just need to register interest to get access afaik. I don't hate automation. sc.ini works out of the box with the default > install of VS 2010. > I don't think my 2010 install is non-standard in any way... 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". > I posted my sc.ini in a prior post. I'll try and get Simon's from him, since he was on 2012.
