On 2/10/2013 10:34 AM, Andrej Mitrovic wrote:
> On 2/9/13, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>> One problem is how to detect the location of the Microsoft linker, the
>> MS runtime library and the platform SDK libraries.
> I already gave Walter a batch file for 2.061 which can be invoked to
> retrieve these paths, but it went completely ignored.
> _______________________________________________
>


These things make me nervous - they are complex and when they go wrong it can be baffling. Is it really a problem to have the user simply edit the file to match his system?
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 10.02.2013 20:37, Walter Bright wrote:
>
> On 2/10/2013 10:34 AM, Andrej Mitrovic wrote:
>> On 2/9/13, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>>> One problem is how to detect the location of the Microsoft linker, the
>>> MS runtime library and the platform SDK libraries.
>> I already gave Walter a batch file for 2.061 which can be invoked to
>> retrieve these paths, but it went completely ignored.
>> _______________________________________________
>>
>
>
> These things make me nervous - they are complex and when they go wrong
> it can be baffling. Is it really a problem to have the user simply edit
> the file to match his system?

If you want to attract newbie programmers, definitely yes. Especially if it isn't explained anywhere.

Doesn't installation descriptions like the one in the wiki ( http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29 ) make you a lot more nervous? There is so much more that can go wrong right now.


_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/10/2013 11:51 AM, Rainer Schuetze wrote:
> On 10.02.2013 20:37, Walter Bright wrote:
>>
>> On 2/10/2013 10:34 AM, Andrej Mitrovic wrote:
>>> On 2/9/13, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>>>> One problem is how to detect the location of the Microsoft linker, the
>>>> MS runtime library and the platform SDK libraries.
>>> I already gave Walter a batch file for 2.061 which can be invoked to
>>> retrieve these paths, but it went completely ignored.
>>> _______________________________________________
>>>
>>
>>
>> These things make me nervous - they are complex and when they go wrong
>> it can be baffling. Is it really a problem to have the user simply edit
>> the file to match his system?
>
> If you want to attract newbie programmers, definitely yes. Especially if it isn't explained anywhere.
>
> Doesn't installation descriptions like the one in the wiki ( http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29 ) make you a lot more nervous? There is so much more that can go wrong right now.

I don't know why Gor felt compelled to make those changes - I don't see why all of them are necessary.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 10.02.2013 21:03, Walter Bright wrote:
>
> On 2/10/2013 11:51 AM, Rainer Schuetze wrote:
>> Doesn't installation descriptions like the one in the wiki (
>> http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
>> ) make you a lot more nervous? There is so much more that can go wrong
>> right now.
>
> I don't know why Gor felt compelled to make those changes - I don't see
> why all of them are necessary.

I agree most of it isn't necessary. I guess it's partly a problem of lacking documentation, but also caused by the "magic" library path settings in link.c, that probably only work with VS2010. It does not work with VS2012 (includes Windows 8 SDK) and probably not with the Windows 7 SDK (includes binaries from VS2008).

My suggestion is trying to make it work out of the box for most installations while removing version specific code from the compiler itself.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/10/2013 12:51 PM, Rainer Schuetze wrote:
> On 10.02.2013 21:03, Walter Bright wrote:
>>
>> On 2/10/2013 11:51 AM, Rainer Schuetze wrote:
>>> Doesn't installation descriptions like the one in the wiki (
>>> http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
>>> ) make you a lot more nervous? There is so much more that can go wrong
>>> right now.
>>
>> I don't know why Gor felt compelled to make those changes - I don't see
>> why all of them are necessary.
>
> I agree most of it isn't necessary. I guess it's partly a problem of lacking documentation, but also caused by the "magic" library path settings in link.c, that probably only work with VS2010. It does not work with VS2012 (includes Windows 8 SDK) and probably not with the Windows 7 SDK (includes binaries from VS2008).
>
> My suggestion is trying to make it work out of the box for most installations while removing version specific code from the compiler itself.
>

I can agree with that. I'm not so sure that should go into this release. I also suspect we are reinventing JSON files badly with dmd.conf. Maybe dmd.conf should be redone as a json file.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/10/13 2:37 PM, Walter Bright wrote:
> These things make me nervous - they are complex and when they go wrong
> it can be baffling. Is it really a problem to have the user simply edit
> the file to match his system?

Not sure how complex the script is, but generally asking users to edit makefiles to match does not scale well at all. IMHO there's a sort of goodness hierarchy when it comes to scripting:

1. one command that does everything, e.g. "./world" or "make world"

10. one command with arguments, and the exact arguments depend on the system, e.g. "make DMD_HOME=/usr/bin/dmd MODEL=64"

100. asking the user to edit configuration files by hand in order to get things done

1000. manual with a recipe with steps for getting things done

10000. folklore on how to get things done

There's a big drop in automation from one level to the next, and in particular there's a surprising drop from the command to the command with specific parameters.


Andrei

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2/10/2013 4:18 PM, Andrei Alexandrescu wrote:
> On 2/10/13 2:37 PM, Walter Bright wrote:
>> These things make me nervous - they are complex and when they go wrong
>> it can be baffling. Is it really a problem to have the user simply edit
>> the file to match his system?
>
> Not sure how complex the script is, but generally asking users to edit makefiles to match does not scale well at all. IMHO there's a sort of goodness hierarchy when it comes to scripting:
>
> 1. one command that does everything, e.g. "./world" or "make world"
>
> 10. one command with arguments, and the exact arguments depend on the system, e.g. "make DMD_HOME=/usr/bin/dmd MODEL=64"
>
> 100. asking the user to edit configuration files by hand in order to get things done
>
> 1000. manual with a recipe with steps for getting things done
>
> 10000. folklore on how to get things done
>
> There's a big drop in automation from one level to the next, and in particular there's a surprising drop from the command to the command with specific parameters.


The general difficulty is one I've had with MS tools from the 1980's: they change in unpredictable ways from release to release, and a *lot* of time gets wasted trying to deal with multiple versions and the endless calls for help about it not working with some random new version. We see this in a smaller way with the evolution of Apple's OSX tools - it's constant breakage. Linux tends to be pretty stable from year to year.

Instead of being terribly clever about it, having a simple edittable file is at least easier to support.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Surely we could have a separate little program that can generate the basic
configuration based on the system is run on?
It should be able to update itself though.

On Feb 10, 2013, at 11:46 PM, Walter Bright <walter@digitalmars.com> wrote:

> Maybe dmd.conf should be redone as a json file.

I think so, there's really no reason to invent a new format.

--
/Jacob Carlborg

On Sun, 10 Feb 2013 16:32:43 -0800
Walter Bright <walter@digitalmars.com> wrote:

> 
> On 2/10/2013 4:18 PM, Andrei Alexandrescu wrote:
> > On 2/10/13 2:37 PM, Walter Bright wrote:
> >> These things make me nervous - they are complex and when they go wrong it can be baffling. Is it really a problem to have the user simply edit the file to match his system?
> >
> > Not sure how complex the script is, but generally asking users to edit makefiles to match does not scale well at all. IMHO there's a sort of goodness hierarchy when it comes to scripting:
> >
> > 1. one command that does everything, e.g. "./world" or "make world"
> >
> > 10. one command with arguments, and the exact arguments depend on the system, e.g. "make DMD_HOME=/usr/bin/dmd MODEL=64"
> >
> > 100. asking the user to edit configuration files by hand in order to get things done
> >
> > 1000. manual with a recipe with steps for getting things done
> >
> > 10000. folklore on how to get things done
> >
> > There's a big drop in automation from one level to the next, and in particular there's a surprising drop from the command to the command with specific parameters.
> 
> 
> The general difficulty is one I've had with MS tools from the 1980's: they change in unpredictable ways from release to release, and a *lot* of time gets wasted trying to deal with multiple versions and the endless calls for help about it not working with some random new version. We see this in a smaller way with the evolution of Apple's OSX tools - it's constant breakage. Linux tends to be pretty stable from year to year.
> 
> Instead of being terribly clever about it, having a simple edittable file is at least easier to support.

Having a simple editable file is great to have as a backup in case things do go wrong or someone wants to do something manually, but that shouldn't preclude making sure things normally "just work" when they can reasonably be made to do so.

People expect anything automatable to be automated. Manual
configuration is sooo "90's linux".
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta