gbc cannot handle import with mixed/other slashes #869
Labels
Comments
chwarr
added a commit
to chwarr/bond
that referenced
this issue
May 5, 2018
Since .bond files can be authored on platforms with different directory separator characters, the paths in build scripts and Bond `import` statements may use a forwardslash when a backslash is expected or vice versa. In order to handle this, gbc now normalizes anything that is a path (file paths, response file items, import directories, import statement paths, output directories, &c.) to use the platform's preferred directory separator character. Tests for C++, C#, and Java have been updated to use some imports with mixed slashes. gbc doesn't use a dedicate type for file paths. `FilePath` is just a type synonym for `String`, so some places may have been inadvertently missed. This does now mean that gbc cannot process files, on, say, Linux, with backslashes in their names. This is expected to be rare, and is deemed an acceptable compromise for a cross-platform tool. Fixes microsoft#869
chwarr
added a commit
that referenced
this issue
May 5, 2018
Since .bond files can be authored on platforms with different directory separator characters, the paths in build scripts and Bond `import` statements may use a forwardslash when a backslash is expected or vice versa. In order to handle this, gbc now normalizes anything that is a path (file paths, response file items, import directories, import statement paths, output directories, &c.) to use the platform's preferred directory separator character. Tests for C++, C#, and Java have been updated to use some imports with mixed slashes. gbc doesn't use a dedicate type for file paths. `FilePath` is just a type synonym for `String`, so some places may have been inadvertently missed. This does now mean that gbc cannot process files, on, say, Linux, with backslashes in their names. This is expected to be rare, and is deemed an acceptable compromise for a cross-platform tool. Fixes #869
chwarr
added a commit
to chwarr/bond
that referenced
this issue
May 5, 2018
Since .bond files can be authored on platforms with different directory separator characters, the paths in build scripts and Bond `import` statements may use a forwardslash when a backslash is expected or vice versa. In order to handle this, gbc now normalizes anything that is a path (file paths, response file items, import directories, import statement paths, output directories, &c.) to use the platform's preferred directory separator character. Tests for C++, C#, and Java have been updated to use some imports with mixed slashes. gbc doesn't use a dedicate type for file paths. `FilePath` is just a type synonym for `String`, so some places may have been inadvertently missed. This does now mean that gbc cannot process files, on, say, Linux, with backslashes in their names. This is expected to be rare, and is deemed an acceptable compromise for a cross-platform tool. Fixes microsoft#869
|
@chwarr when will the change be merged ? Also, are you going to create a release for this change ? |
|
Should be merged by end-of-day, Pacific time, on Wednesday, May 9, 2018. |
chwarr
added a commit
to chwarr/bond
that referenced
this issue
May 10, 2018
Since .bond files can be authored on platforms with different directory separator characters, the paths in build scripts and Bond `import` statements may use a forwardslash when a backslash is expected or vice versa. In order to handle this, gbc now normalizes anything that is a path (file paths, response file items, import directories, import statement paths, output directories, &c.) to use the platform's preferred directory separator character. Tests for C++, C#, and Java have been updated to use some imports with mixed slashes. gbc doesn't use a dedicate type for file paths. `FilePath` is just a type synonym for `String`, so some places may have been inadvertently missed. This does now mean that gbc cannot process files, on, say, Linux, with backslashes in their names. This is expected to be rare, and is deemed an acceptable compromise for a cross-platform tool. Fixes microsoft#869
lalo
pushed a commit
that referenced
this issue
May 11, 2018
Since .bond files can be authored on platforms with different directory separator characters, the paths in build scripts and Bond `import` statements may use a forwardslash when a backslash is expected or vice versa. In order to handle this, gbc now normalizes anything that is a path (file paths, response file items, import directories, import statement paths, output directories, &c.) to use the platform's preferred directory separator character. Tests for C++, C#, and Java have been updated to use some imports with mixed slashes. gbc doesn't use a dedicate type for file paths. `FilePath` is just a type synonym for `String`, so some places may have been inadvertently missed. This does now mean that gbc cannot process files, on, say, Linux, with backslashes in their names. This is expected to be rare, and is deemed an acceptable compromise for a cross-platform tool. Fixes #869
|
@chwarr what is the current target date for 8.0 release ? |
Tuesday, May 29, 2018 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Linux, gbc cannot handle import statements with mixed or backslashes.
Given ./inc/one/two/a.bond:
And ./b.bond:
Run codegen as:
Expected results:
b_types.cs is created with references to
a.fooActual results:
Import statements with mixed or backslashes are going to be common if the .bond files were originally authored on Windows. (gbc on Windows can handle mixed slashes just fine.)
The text was updated successfully, but these errors were encountered: