Any custom modification swill overwrite the original sc.ini file. The compiler should copy(rename) or create the file on demand when it is ran and does not exist in the same path as the compiler.

This way one can unzip over a previous install without losing the original sc.ini file. It is a pain to have to remember to back it up every time(given if one updates slowly).

That or simply let an alternative "sc.ini" file be used if it exists.

e.g., if sc-main.ini exists then it will use that first and if not then it defaults to sc.ini. sc-main.ini is not included in the distribution.

On Thursday, 17 May 2018 at 07:38:50 UTC, IntegratedDimensions wrote:
> This way one can unzip over a previous install without losing the original sc.ini file. It is a pain to have to remember to back it up every time(given if one updates slowly).

You only need to back it up once.

> That or simply let an alternative "sc.ini" file be used if it exists.

There's -conf switch: https://dlang.org/dmd-windows.html#switch-conf

On Thursday, 17 May 2018 at 07:38:50 UTC, IntegratedDimensions wrote:
> This way one can unzip over a previous install without losing the original sc.ini file.

Also that's not a correct way to update, you should unzip into an empty folder or stray files can be left from the previous installation and cause compilation and runtime errors.

On Thursday, 17 May 2018 at 07:38:50 UTC, IntegratedDimensions wrote:
> Any custom modification swill overwrite the original sc.ini file. The compiler should copy(rename) or create the file on demand when it is ran and does not exist in the same path as the compiler.

Not detracting from your argument, but according to https://dlang.org/dmd-windows.html#sc-ini , you can place your custom version in %HOME%/sc.ini.

On Thursday, 17 May 2018 at 08:53:06 UTC, Vladimir Panteleev wrote:
> On Thursday, 17 May 2018 at 07:38:50 UTC, IntegratedDimensions wrote:
>> Any custom modification swill overwrite the original sc.ini file. The compiler should copy(rename) or create the file on demand when it is ran and does not exist in the same path as the compiler.
>
> Not detracting from your argument, but according to https://dlang.org/dmd-windows.html#sc-ini , you can place your custom version in %HOME%/sc.ini.

This may be a suitable solution. While it has some overhead and pollutes the environment, it at least offers a working alternative unlike other (non)"solutions".

It would be better if HOME wasn't so general since other applications could collide with it in usage. DMD_HOME would be better or in addition to.

On Friday, 18 May 2018 at 00:05:49 UTC, IntegratedDimensions wrote:
> This may be a suitable solution. While it has some overhead and pollutes the environment, it at least offers a working alternative unlike other (non)"solutions".
>
> It would be better if HOME wasn't so general since other applications could collide with it in usage. DMD_HOME would be better or in addition to.

This is generally not considered a problem because sc.ini is a unique-enough filename. It is certainly not considered a problem on POSIX platforms today (following freedesktop recommendations), where the expectation is that programs will use their own unique-enough file/directory names (generally named after the software) in /etc or ~/.config, or as dictated by $XDG_CONFIG_DIRS / $XDG_CONFIG_HOME if set (which they usually aren't).

You'd probably want to set HOME to the same value as %USERPROFILE%, as that best maps to its usage on POSIX (where it is generally always set). That would also give it a good value for any other POSIX-ish software that would happen to use it (then there would be no need to worry about collisions because it's set to a good value). You could then place your sc.ini there.

On Thursday, May 17, 2018 08:51:34 Kagamin via Digitalmars-d wrote:
> On Thursday, 17 May 2018 at 07:38:50 UTC, IntegratedDimensions
>
> wrote:
> > This way one can unzip over a previous install without losing the original sc.ini file.
>
> Also that's not a correct way to update, you should unzip into an empty folder or stray files can be left from the previous installation and cause compilation and runtime errors.

Exactly. If you unzip on top of an existing install, there is zero guarantee that you'll get a working install. Such an approach is not supported at all. If you want to use the zip file, then you should always unzip somewhere fresh and then change stuff like sc.ini or dmd.conf afterwards. The layout of the zip file is not guaranteed, and even if the layout stays the same, sometimes modules are moved or renamed in ways that code won't break if phobos is installed poperly but _will_ break if you unzip on top odf an existing install - e.g. if a module gets broken up into a package, you'll end up with both the module from the previous release and the directory from the current one. So, fundamentally, you can't expect to be able to just unzip onto an existing install and have things work. Either use a proper installer or always unzip in a fresh location and never overwrite.

- Jonathan M Davis