generating paths for a different system than is being run (Print a windows path string, from a linux binary)
generating paths for the system being compiled on, but different than the system that will run on (cross compiling)
Motivation
I needed it and found I had to start copying code from the stdlib and pasting it into my project with slight modifications. See https://github.com/wltsmrz/nim_zstd/pull/3) for an example of this issue and my attempt to solve it without delving into the stdlib.
What problems does it solve?
This solves 2 problems.
Problem A where you want to manipulate and create paths relative to a system different than you are running on.
Problem B that is a version of A where you are cross-compiling from linux to windows, and at compile-time are using these path string tools to create library paths for compilation. These procs, because of --os:windows or -d:mingw will operate as if you are on a windows system, so now your paths to the C library files are all using backslashes.
Who can benefit from it?
Me. But also people who are doing cross platform compiling.
Description
Add a default argument to the existing procs like joinPath that allows to specify the resulting DirSep that should be used to generate the string.
What are the downsides of this proposal?
The user code must include the control flow for when to add these arguments to joinPath etc.
The change must propagate through a couple layers of proc calls within the stdlib.
Examples
when defined(mingw):
const LibBasePath = currentSourcePath.parentDir(sep='/')
Before
(skipped)
After
The following procs may be candidate for this addition of the sep argument. But probably most of the logic for this change will be in one place: normalizePath, which is called by many other procs.
absolutePath
cmpPaths
extractFilename
getCacheDir
getCurrentDir
getHomeDir
getTempDir
isAbsolute
isRelativeTo
isRootDir
joinPath
lastPathPart
normalizedPath
normalizePath
normalizePathEnd
parentDir
relativePath
splitFile
splitPath
tailDir
unixToNativePath
parentDirs
Backward incompatibility
There should be no backwards incompatibility, as this code would be "opt-in."
path functionality for heterogeneous systems
Abstract
This is specific for the following use cases:
Motivation
I needed it and found I had to start copying code from the stdlib and pasting it into my project with slight modifications. See https://github.com/wltsmrz/nim_zstd/pull/3) for an example of this issue and my attempt to solve it without delving into the stdlib.
What problems does it solve? This solves 2 problems. Problem A where you want to manipulate and create paths relative to a system different than you are running on. Problem B that is a version of A where you are cross-compiling from linux to windows, and at compile-time are using these path string tools to create library paths for compilation. These procs, because of
--os:windowsor-d:mingwwill operate as if you are on a windows system, so now your paths to the C library files are all using backslashes.Who can benefit from it?
Me. But also people who are doing cross platform compiling.
Description
Add a default argument to the existing procs like
joinPaththat allows to specify the resulting DirSep that should be used to generate the string.What are the downsides of this proposal?
The user code must include the control flow for when to add these arguments to
joinPathetc. The change must propagate through a couple layers of proc calls within the stdlib.Examples
Before
(skipped)
After
The following procs may be candidate for this addition of the
separgument. But probably most of the logic for this change will be in one place: normalizePath, which is called by many other procs.Backward incompatibility
There should be no backwards incompatibility, as this code would be "opt-in."