FWD » Build and Source Control

From Ovidiu:
The no-space constraint if caused by parameters received by mingw compiler. The (spaced-)path will be seen as two paths and files won't be found. Please see my mail from last night for two workaround solutions. I guess the native target in gradle/ant can be fixed to support this, by passing the paths to JAVA_HOME/JRE_HOME in double quotes.

ant tool uses JAVA_HOME to built the path for include headers for gcc.

If JDK is already installed or to avoid installing it to a different location, we just need to set JAVA_HOME environment variable so it does not contain spaces (which will be sent to gcc and will split paths to multiple parameters).

The solution is to replace file-tokens that contains spaces with their legacy 8.3 filename that are space-less. Usually the problem tokens are Program Files and Program Files (x86) if a 32 bit Java is installed on a 64-bit OS. The default legacy file name for these are PROGRA~1 and PROGRA~2, but these can be different in some conditions, for example if Windows was not clean installed. In this case we need to use

dir C:\ /X

command to find out the legacy names. They are found in second to the last column, like this:

16-Nov-15  02:45 PM     <DIR>            PROGRA~1     Program Files
16-Nov-15  02:48 PM     <DIR>            PROGRA~2     Program Files (x86)
16-Nov-15  02:51 PM     <DIR>                         Users
16-Nov-15  02:40 PM     <DIR>                         Windows

If needed (the complete path to JDK contains multiple tokens with spaces) repeat the above process for the parent of each affected token.

In the correct value for this environment variable when JDK is installed in the default location, should look like this:

JAVA_HOME=C:\PROGRA~1\Java\jdk1.8.0_121

After search for solution I've the following conclusion: This is the really GCC package limitation that does not like the spaces in include file path. So I would offer to use the following scenarios depending on target system configuration:

1. System with no JDK yet installed. The approach is to install into directory with no spaces inside. Then make respective environment variables.

2. System with JDK already installed into something like "Program Files\path to JDK" containing spaces. In this case the developer will need to create symbolic link to JDK that will not have the spaces:

mklink /D SomePathWithNoSpaces "The target path\to JDK with\spaces inside" 

Please update our documentation (Install the JDK) to explain the full details. You will see that this document already has one workaround and refers to #3273. It is OK to leave that workaround in place as well as add this additional discussion.

Greg Shah wrote:

Please update our documentation (Install the JDK) to explain the full details. You will see that this document already has one workaround and refers to #3273. It is OK to leave that workaround in place as well as add this additional discussion.

OK. Done.

The documentation update is good.

This is the really GCC package limitation that does not like the spaces in include file path.

To confirm: there is nothing we can do in our makefile to avoid this issue?

Greg Shah wrote:

This is the really GCC package limitation that does not like the spaces in include file path.

To confirm: there is nothing we can do in our makefile to avoid this issue?

Whatever we do in makefile - we can not change the current path to JDK that can have spaces. Otherwise this will be path to other installation and this means technically we just make additional copy of the same JDK. This can complicate support of the existed JDK. As I can see this is not a GCC bug but intention. Some discussion:
https://github.com/chef/omnibus/issues/685
This is in our case -Ipath option issue. I have tried to enclose in "", '' or even use %20 instead of space or escape it with \ or even ^ (caret). Nothing helps.

So I think it will be the better and safer to just avoid spaces in path.