Suggestion to make the configuration able to handle windows

[mattgodbolt]

Suggestion:

Working on a win32 environment had some caveats. It should be mentioned in the windows docs that the colon separator : conflicts with absolute windows paths, and that quoting doesn't resolve that. It needs to be overridden in the files that parse configuration (it's already overridden for library paths due to earlier issue that was resolved with #540, specifically this)

An example of an override I needed to do was for the compiler absolute path:

diff --git a/lib/compiler-finder.js b/lib/compiler-finder.js
index 78d8dbf..9ee8cdd 100644
--- a/lib/compiler-finder.js
+++ b/lib/compiler-finder.js
@@ -335,7 +335,7 @@ export class CompilerFinder {
                 }
                 return this.compilerProps(langId, `group.${groupName}.${name}`, parentProps(langId, name, def));
             };
-            const exes = _.compact(this.compilerProps(langId, `group.${groupName}.compilers`, '').split(':'));
+            const exes = _.compact(this.compilerProps(langId, `group.${groupName}.compilers`, '').split(';'));
             logger.debug(`Processing compilers from group ${groupName}`);
             return Promise.all(exes.map(compiler => this.recurseGetCompilers(langId, compiler, props)));
         }
@@ -385,7 +385,7 @@ export class CompilerFinder {
     }
 
     getExes() {
-        const langToCompilers = this.compilerProps(this.languages, 'compilers', '', exs => _.compact(exs.split(':')));
+        const langToCompilers = this.compilerProps(this.languages, 'compilers', '', exs => _.compact(exs.split(';')));
         this.addNdkExes(langToCompilers);
         logger.info('Exes found:', langToCompilers);
         return langToCompilers;

Although this isn't ideal. What's ideal would be perhaps something along the lines of:

const CONFSEP = process.platform === 'win32' ? ';' : ':';
// use CONFSEP wherever ':' is currently used to parse options

Originally posted by @hyphenrf in #2853 (comment)

[partouf]

I think in general we want to avoid people setting paths in the .compilers property. I know we have some examples and defaults doing things like compilers=/usr/bin/gcc - but we'll always make groups and define the compilers with .exe and .semver etc.

Maybe instead we should make the defaults and examples reflect that and maybe pretend you can't actually point to paths directly from the compilers property.

So I don't know if it's worth implementing this, also because it's a breaking change.

[hyphenrf]

The diff above isn't meant to be implemented, it's a bad idea haha
what's worth considering I think is the lines below it, defining a separator constant.

My impression is that godbolt.org works on a linux env anyway, this suggestion was built on that impression, because CE would only work on a windows env when pulled and deployed locally.. where we usually define lang.local.properties etc.. Files that are ad-hoc and never submitted upstream.
Does the exe property properly handle colons for absolute windows paths? And what about other properties that take paths like objdumper?

I imagine it won't be as simple as a global check on win32 followed by a constant definition, but I fail to see where it may be breaking otherwise..

[partouf]

Does the exe property properly handle colons for absolute windows paths? And what about other properties that take paths like objdumper?

Yes, most of these path-taking properties don't do any splitting. And a couple of properties like path, includePath, libPath do splitting, but change behaviour when running on Windows.
There are a couple of examples for windows properties over here https://github.com/compiler-explorer/compiler-explorer/tree/main/docs

I imagine it won't be as simple as a global check on win32 followed by a constant definition, but I fail to see where it may be breaking otherwise..

It will break the Windows MSVC instances and local Windows installations if they are updated (as they use : as separators between groupnames and compilernames)

[AbrilRBS]

I wonder if something like c7af543 could be useful to try to implement properly

[partouf]

Related and partially fixed by 38cf38f

Like I said, I don't think we should do more that may break existing configurations. I'll close this issue until we actually encounter some more of these problems.