One of the reasons why wndows support is not so great.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

One of the reasons why wndows support is not so great.

Jan Baeyens

Hi all

I have created a bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330 that creates some unlikely to happen and  hard to understand behaviour that is most likely to happen on windows os.

When working with environment variables \ is used to avoid macro expansion.

Because of that something like

${ProjDirPath}\${ConfigName}
will not expand ConfigName
also
${ProjDirPath}${DirectoryDelimiter}${ConfigName}
will not expand correctly on windows because DirectoryDelimiter will expand to \ before ConfigName is handled.

Though I think the code could be improved so that at least ${ProjDirPath}${DirectoryDelimiter}${ConfigName} works properly the real issue is that the use of \ as escape key is a bad choice in windows environment variables.

As to the impact of (not) changing the escape key. I fear the key is at least used by CDT gnu managed build. But more importantly, replacing \ by another key will cause compatibility issues. Keeping it will mean: "remaining with occasional weird windows problems"

Jantje

PS Don't get me wrong, I do not think this is a urgent issue. It is however important to understand windows specific issues.
I worked around it by doing the expansion myself
        //work around needed because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330
        //it should have been
        //A.BUILD.PATH={ProjDirPath}{DirectoryDelimiter}{ConfigName}
        // in pre_processing_platform_default.txt
        String buildPath=confDesc.getProjectDescription().getProject().getLocation().append(confDesc.getName()).toOSString();
        setBuildEnvironmentVariable(contribEnv, confDesc, "A.BUILD.PATH", buildPath);
        //end of workaround


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: One of the reasons why wndows support is not so great.

Jan Baeyens

Rereading this I see an error.

"will not expand ConfigName" should say

will not expand ConfigName and remove the \

Op 20/02/2020 om 15:22 schreef Jan Baeyens:

Hi all

I have created a bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330 that creates some unlikely to happen and  hard to understand behaviour that is most likely to happen on windows os.

When working with environment variables \ is used to avoid macro expansion.

Because of that something like

${ProjDirPath}\${ConfigName}
will not expand ConfigName
also
${ProjDirPath}${DirectoryDelimiter}${ConfigName}
will not expand correctly on windows because DirectoryDelimiter will expand to \ before ConfigName is handled.

Though I think the code could be improved so that at least ${ProjDirPath}${DirectoryDelimiter}${ConfigName} works properly the real issue is that the use of \ as escape key is a bad choice in windows environment variables.

As to the impact of (not) changing the escape key. I fear the key is at least used by CDT gnu managed build. But more importantly, replacing \ by another key will cause compatibility issues. Keeping it will mean: "remaining with occasional weird windows problems"

Jantje

PS Don't get me wrong, I do not think this is a urgent issue. It is however important to understand windows specific issues.
I worked around it by doing the expansion myself
        //work around needed because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330
        //it should have been
        //A.BUILD.PATH={ProjDirPath}{DirectoryDelimiter}{ConfigName}
        // in pre_processing_platform_default.txt
        String buildPath=confDesc.getProjectDescription().getProject().getLocation().append(confDesc.getName()).toOSString();
        setBuildEnvironmentVariable(contribEnv, confDesc, "A.BUILD.PATH", buildPath);
        //end of workaround


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: One of the reasons why wndows support is not so great.

15 knots
In reply to this post by Jan Baeyens
Did you try to use forward slashes (Unix path separators)? AFAIK, the
windows filesystem functions accept forward slashes, too.
Well cmd.exe is a different thing:-)

Am Do., 20. Feb. 2020 um 15:20 Uhr schrieb Jan Baeyens <[hidden email]>:

>
> Hi all
>
> I have created a bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330 that creates some unlikely to happen and  hard to understand behaviour that is most likely to happen on windows os.
>
> When working with environment variables \ is used to avoid macro expansion.
>
> Because of that something like
>
> ${ProjDirPath}\${ConfigName}
> will not expand ConfigName
> also
> ${ProjDirPath}${DirectoryDelimiter}${ConfigName}
> will not expand correctly on windows because DirectoryDelimiter will expand to \ before ConfigName is handled.
>
> Though I think the code could be improved so that at least ${ProjDirPath}${DirectoryDelimiter}${ConfigName} works properly the real issue is that the use of \ as escape key is a bad choice in windows environment variables.
>
> As to the impact of (not) changing the escape key. I fear the key is at least used by CDT gnu managed build. But more importantly, replacing \ by another key will cause compatibility issues. Keeping it will mean: "remaining with occasional weird windows problems"
>
> Jantje
>
> PS Don't get me wrong, I do not think this is a urgent issue. It is however important to understand windows specific issues.
> I worked around it by doing the expansion myself
>         //work around needed because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330
>         //it should have been
>         //A.BUILD.PATH={ProjDirPath}{DirectoryDelimiter}{ConfigName}
>         // in pre_processing_platform_default.txt
>         String buildPath=confDesc.getProjectDescription().getProject().getLocation().append(confDesc.getName()).toOSString();
>         setBuildEnvironmentVariable(contribEnv, confDesc, "A.BUILD.PATH", buildPath);
>         //end of workaround
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: One of the reasons why wndows support is not so great.

Jan Baeyens

As you can read in the issue

I found this issue because / causes issues elsewhere so I needed to change to \ causing this issue
FYI the windows copy command is not so happy with /.

Apart from that; I mentioned the issue in the dev list because I understood that CDT windows support is not as good as linux support. Sloeber build on CDT works great in windows but this issue demonstrates deep down code that cause pure windows users to have a lesser CDT experience.
FYI It took me quite some time to figure out what was going on -after simply changing a / to \) and I have extensive CDT, eclipse, java and development experience.

Jantje

Op 26/02/2020 om 21:00 schreef 15 knots:
Did you try to use forward slashes (Unix path separators)? AFAIK, the
windows filesystem functions accept forward slashes, too.
Well cmd.exe is a different thing:-)

Am Do., 20. Feb. 2020 um 15:20 Uhr schrieb Jan Baeyens [hidden email]:
Hi all

I have created a bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330 that creates some unlikely to happen and  hard to understand behaviour that is most likely to happen on windows os.

When working with environment variables \ is used to avoid macro expansion.

Because of that something like

${ProjDirPath}\${ConfigName}
will not expand ConfigName
also
${ProjDirPath}${DirectoryDelimiter}${ConfigName}
will not expand correctly on windows because DirectoryDelimiter will expand to \ before ConfigName is handled.

Though I think the code could be improved so that at least ${ProjDirPath}${DirectoryDelimiter}${ConfigName} works properly the real issue is that the use of \ as escape key is a bad choice in windows environment variables.

As to the impact of (not) changing the escape key. I fear the key is at least used by CDT gnu managed build. But more importantly, replacing \ by another key will cause compatibility issues. Keeping it will mean: "remaining with occasional weird windows problems"

Jantje

PS Don't get me wrong, I do not think this is a urgent issue. It is however important to understand windows specific issues.
I worked around it by doing the expansion myself
        //work around needed because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=560330
        //it should have been
        //A.BUILD.PATH={ProjDirPath}{DirectoryDelimiter}{ConfigName}
        // in pre_processing_platform_default.txt
        String buildPath=confDesc.getProjectDescription().getProject().getLocation().append(confDesc.getName()).toOSString();
        setBuildEnvironmentVariable(contribEnv, confDesc, "A.BUILD.PATH", buildPath);
        //end of workaround

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev