Prevent all use of windows path separators #286
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR ensures unix-style path separators are used everywhere within
CodeGeneration. This solves at least two issues:include("a\\b.jl")when created on Windows, making the result non-portable (include's in hierarchic proto definitions use static path separator #284).relative_pathsand included from another file, these could be considered as different files due to different path separators. This would lead to duplicatedincludes in the generated package file.These changes fixes so that
"/"is used as a path separator in all internals and outputs ofCodeGeneration. The basic assumption is that everything already works correctly on linux, so the behaviour on windows is made more like linux through the following steps:protojlinto unix-style paths.joinpath_unix,relpath_unixandnormpath_unixeverywhere inCodeGeneration.jl. These behave exactly like theBasecounterparts on unix systems, but use unix separators also on windows. This helps make code generation independent of the platform.includestatements ensuring that the path is free from windows path separators.In order to minimize the risk that this issue appears again in the future, calling
joinpath,normpathorrelpathwithinCodeGenerationwill now result in a helpful error message. To get the normal platform-dependent behavior,Base.<function>is still possible.In all cases where the unit checks that the output contains an
include, the included path has now been hard-coded to use/as a separator. This means that we now test for the same result regardless of which platform the tests run on. (Related info:Base.jluses/as path separators, so I cannot see any reason why this should not be safe).