Use SL4 API and drop support for SL3

[jfcherng]

@kaste I have changed linter.py to https://github.com/SublimeLinter/SublimeLinter-gcc/blob/d5ada91f87dbd5a5a6c5cfa825b3ed6484ab78af/linter.py. But it failed with ValueError: path is on mount 'C:', start on mount 'E:'. I do a quick search and it looks like a problem in SL itself but I don't think I am using symlink in this case?

SublimeLinter: linter.py:1056         g++: Checking lint mode 'background' vs lint reason 'on_load'.  Ok.
SublimeLinter: #1 linter.py:1073      g++: linting 'test.cpp'
SublimeLinter: #1 util.py:136         PATH:
    C:\mingw64\bin
    ... some other paths
SublimeLinter: #1 __init__.py:1273    ERROR: Unhandled exception:
Traceback (most recent call last):
  File "C:\Users\Clover\AppData\Roaming\Sublime Text 3\Installed Packages\SublimeLinter.sublime-package\lint/backend.py", line 155, in execute_lint_task
    errors = linter.lint(code, view_has_changed)
  File "C:\Users\Clover\AppData\Roaming\Sublime Text 3\Installed Packages\SublimeLinter.sublime-package\lint/linter.py", line 1085, in lint
    output = self.run(cmd, code)
  File "C:\Users\Clover\AppData\Roaming\Sublime Text 3\Installed Packages\SublimeLinter.sublime-package\lint/linter.py", line 1469, in run
    return self.communicate(cmd, code)
  File "C:\Users\Clover\AppData\Roaming\Sublime Text 3\Installed Packages\SublimeLinter.sublime-package\lint/linter.py", line 1480, in communicate
    return self._communicate(cmd, code)
  File "C:\Users\Clover\AppData\Roaming\Sublime Text 3\Installed Packages\SublimeLinter.sublime-package\lint/linter.py", line 1576, in _communicate
    'Running ...', cmd, uses_stdin, cwd, view, env=None))
  File "C:\Users\Clover\AppData\Roaming\Sublime Text 3\Installed Packages\SublimeLinter.sublime-package\lint/linter.py", line 1668, in make_nice_log_message
    rel_filename = os.path.relpath(filename, cwd)
  File "./python3.3/ntpath.py", line 564, in relpath
ValueError: path is on mount 'C:', start on mount 'E:'
SublimeLinter: sublime_linter.py:482  Linting 'test.cpp' took 0.05s

SL settings:

        "gcc": {
            "disable": false,
            // "executable": "gcc",
            "args": ["-std=c90", "-fsyntax-only"],
            "I": [
                "${folder}/include",
                "C:\\boost\\include\\boost-1_70",
                "/usr/local/include",
                "/usr/local/halide/include",
                "/usr/local/systemc-2.3.1/include",
            ],
            "excludes": [],
        },
        "g++": {
            "disable": false,
            // "executable": "g++",
            "args": ["-std=c++17", "-fsyntax-only"],
            "I": [
                "${folder}/include",
                "C:\\boost\\include\\boost-1_70",
                "/usr/local/include",
                "/usr/local/halide/include",
                "/usr/local/systemc-2.3.1/include",
            ],
            "excludes": [],
        },

[jfcherng]

Okay. It looks like I am in another project which is mounted on E: and I just casually open a test.cpp from C: and SL gets broken like above.

[jfcherng]

@kaste Another thing that I noticed is that if I fill the executable setting with g++, SL cannot find it. But if I fill it with ["g++"], SL is able to find it... I am not sure is this by-design or a bug. http://www.sublimelinter.com/en/stable/linter_settings.html#executable

        "g++": {
            "disable": false,
            // "executable": "g++", // <----------- unable to locate "g++"
            "executable": ["g++"], // <-------------- works, omitted will work as well
            "args": ["-std=c++17", "-fsyntax-only"],
            "I": [
                "${folder}/include",
                "C:\\boost\\include\\boost-1_70",
                "/usr/local/include",
                "/usr/local/halide/include",
                "/usr/local/systemc-2.3.1/include",
            ],
            "excludes": [],
        },

[jfcherng]

Since the current linter cannot work with the latest SL4, merging this is better than nothing. If there are some edge cases that are not considered, we can fix them later.

[kaste]

You hard-code the executable in the cmd to gcc or g++ so there is no need and you actually shouldn't have to define the executable just to tell it the same name.

If you set executable it currently assumes that you point it to a full abs path not just a name the system has to resolve. (But we could change that.) If you provide an array we currently skip all checks and just assume a happy path. (We can probably change that as well.)

[jfcherng]

@kaste I add it in the default settings mainly in order to make it more clear about how to change it and make it work. Say a person wants to use arm-none-eabi-gcc but he may curious about the unable to locate "arm-none-eabi-gcc" while it's indeed in his OS' PATH. Mandatorily using an absolute path here sounds weird to me since PATH can be always a fallback to be searched from.

[kaste]

I made an upstream issue.