R1910 patch : Sdcc in windows

This patch tries to addres the following issues in windows:
- If sdcc is not in the enviroment PATH , it won't work. This patch add compiler's tool path to PATH before run it.
- After choosing compiler's tool path use the dir dialog, "\" is auto added to path's tail. But QT uses "/" internally even in windows, and QProcess can't correctly run a command whose path mixes "/" and "\". This patch make getDirDialog() auto add "/" instead of "\" in windows.

- If sdcc is not in the enviroment PATH , it won't work. This patch add compiler's tool path to PATH before run it.

SDCC is working for me without being in the PATH. Which problem do you experience?
In any case, adding tool path to PATH might cause problems, it could be another one in PATH already.
The whole point of "Tool Path" property is to execute the tool with full path.

- After choosing compiler's tool path use the dir dialog, "\" is auto added to path's tail. But QT uses "/" internally even in windows, and QProcess can't correctly run a command whose path mixes "/" and "\". This patch make getDirDialog() auto add "/" instead of "\" in windows.

I think it is solved at Rev 1912, along with other issue.
Let me know if it does not work for you.

arcachofo wrote:

- If sdcc is not in the enviroment PATH , it won't work. This patch add compiler's tool path to PATH before run it.

SDCC is working for me without being in the PATH. Which problem do you experience?
In any case, adding tool path to PATH might cause problems, it could be another one in PATH already.
The whole point of "Tool Path" property is to execute the tool with full path.

I'm using sdcc 4.3.2 downloaded from sourceforge.

It will complain like the following:

Code:


sdcpp.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
compilation terminated.
at 1: warning 190: ISO C forbids an empty translation unit
subprocess error 1


The tool path is only added to the compiler object's member property "m_compProcess"'s environment when it's used to execute the tools, so I think it should not be harmful.

royqh1979 wrote:

arcachofo wrote:

- If sdcc is not in the enviroment PATH , it won't work. This patch add compiler's tool path to PATH before run it.

SDCC is working for me without being in the PATH. Which problem do you experience?
In any case, adding tool path to PATH might cause problems, it could be another one in PATH already.
The whole point of "Tool Path" property is to execute the tool with full path.

I'm using sdcc 4.3.2 downloaded from sourceforge.

It will complain like the following:

Code:


sdcpp.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
compilation terminated.
at 1: warning 190: ISO C forbids an empty translation unit
subprocess error 1


The tool path is only added to the compiler object's member property "m_compProcess"'s environment when it's used to execute the tools, so I think it should not be harmful.

And there's one more issue with sdcc compiler:
- In sdcc compiler's compile(), packihx is executed without m_toolPath as prefix. So if it's not in the path, packihx would fail and a zero size hex file would be created, even if sdcc did successfully compiled.

- In sdcc compiler's compile(), packihx is executed without m_toolPath as prefix. So if it's not in the path, packihx would fail and a zero size hex file would be created, even if sdcc did successfully compiled.

Yes there is an error here.

Another option is add the following code in beginning of sdcc debugger's compile(), before Compiler::compile() is called.

Which add m_toolPath to m_compProcess's PATH env, and only affects sdcc.

Code:


    QProcessEnvironment env = QProcessEnvironment::systemEnvironment();
    QString path = env.value( "PATH" );
    if ( !path.isEmpty() ) {
        path = m_toolPath + PATH_SEPARATOR + path;
    } else {
        path = m_toolPath;
    }
    env.insert( "PATH",path );
    m_compProcess.setProcessEnvironment( env );


- In sdcc compiler's compile(), packihx is executed without m_toolPath as prefix. So if it's not in the path, packihx would fail and a zero size hex file would be created, even if sdcc did successfully compiled.

Hopefully solved at Rev 1918.

Another option is add the following code in beginning of sdcc debugger's compile(), before Compiler::compile() is called.

Which add m_toolPath to m_compProcess's PATH env, and only affects sdcc.

I tried to reproduce the issue to investigate it, but I couldn't, at least with default compiler arguments.
In any case if a compiler needs to be in PATH to work properly it should be done permanently in the system, if not how do you use it?.
I guess the installer should add it to PATH or something like that.

arcachofo wrote:

- In sdcc compiler's compile(), packihx is executed without m_toolPath as prefix. So if it's not in the path, packihx would fail and a zero size hex file would be created, even if sdcc did successfully compiled.

Hopefully solved at Rev 1918.

Another option is add the following code in beginning of sdcc debugger's compile(), before Compiler::compile() is called.

Which add m_toolPath to m_compProcess's PATH env, and only affects sdcc.

I tried to reproduce the issue to investigate it, but I couldn't, at least with default compiler arguments.
In any case if a compiler needs to be in PATH to work properly it should be done permanently in the system, if not how do you use it?.
I guess the installer should add it to PATH or something like that.

It's a bug of sdcc's installer. cc1 should be installed in sdcc/libexec/sdcc, but it's installed to sdcc/bin.

I only use it occasionally and don't want to add sdcc/bin to PATH permanently.

It's a bug of sdcc's installer and not correctly fixed until now. cc1 should be installed in sdcc/libexec/sdcc, but it's installed to sdcc/bin.

I only use it occasionally and don't want to add sdcc/bin to PATH permanently.

Maybe a bug in the development branch?
I could not find sdcc 4.3.2 in Sourceforge.
I tried 4.3.0 in Linux and Windows, without installing, just downloaded and it works ok.