[CMake] Make GNU-style response files for long argument lists #18958
Conversation
|
@swift-ci Please smoke test |
| string(RANDOM file_name) | ||
| set(file_path "${CMAKE_CURRENT_BINARY_DIR}/${file_name}.txt") | ||
| file(WRITE "${file_path}" "${source_files}") | ||
| string(REPLACE ";" "'\n'" source_files_quoted "${source_files}") | ||
| file(WRITE "${file_path}" "'${source_files_quoted}'") |
There was a problem hiding this comment.
Im worried about how this expansion works on Windows. The shell escaping there is weird and the quoting here I believe will go wrong. Note that shlex behaves differently on Windows and unices, so the behaviour of the quoting is relevant to that too
There was a problem hiding this comment.
One of shlex's arguments is whether it behaves POSIXly, which I passed True to. Still, I'd love to test this on a Windows machine; I just don't have one available today.
utils/line-directive
Outdated
| # "Make an iterator out of shlex.shlex.get_token, then consume items | ||
| # until it returns None." (Then eagerly convert the result to a list so | ||
| # that we can close the file.) | ||
| return list(iter(shlex.shlex(files, file_path, True).get_token, None)) |
There was a problem hiding this comment.
I'd prefer for the True value we use a named argument, if that's shell it makes it much easier to understand what's going on here.
There was a problem hiding this comment.
I'd love to as well; unfortunately shlex doesn't document a name.
There was a problem hiding this comment.
I believe the name is posix, the function (well, class constructor) signature is shlex.shlex(instream=None, infile=None, posix=False), source Lib/shlex.py:23
...i.e. an actual shell-like argument list, rather than a semicolon-separated list (CMake's internal stringification mechanism for lists). Apart from being a little easier to read, this also works directly with the response file support in swiftc itself now (not depending on utils/line-directive). (It's still not /quite/ enough to expand on a command-line, though, since that will escape the quotes. The 'sed' command can get around that: $(sed "s/'//g" foo.txt).)
jrose-apple
force-pushed
the
stimulus
branch
from
08a8a83 to
bd03b27
Compare
|
@swift-ci Please clean smoke test |
|
Did either of you have further comments? |
|
@Rostepher @compnerd ping |
|
This looks good to me, I have no further comments nor suggestions. 👍 |
|
@compnerd, any further thoughts? |
|
@jrose-apple - sorry, forgot about this. Lets go ahead and merge this. If there are problems with Windows, we can fix them then. |
|
Let's make sure this still integrates cleanly. @swift-ci Please smoke test |
…ang#18958) ...i.e. an actual shell-like argument list, rather than a semicolon-separated list (CMake's internal stringification mechanism for lists). Apart from being a little easier to read, this also works directly with the response file support in swiftc itself now (not depending on utils/line-directive). (It's still not /quite/ enough to expand on a command-line, though, since that will escape the quotes. The 'sed' command can get around that: $(sed "s/'//g" foo.txt).)
…ang#18958) ...i.e. an actual shell-like argument list, rather than a semicolon-separated list (CMake's internal stringification mechanism for lists). Apart from being a little easier to read, this also works directly with the response file support in swiftc itself now (not depending on utils/line-directive). (It's still not /quite/ enough to expand on a command-line, though, since that will escape the quotes. The 'sed' command can get around that: $(sed "s/'//g" foo.txt).)
...i.e. an actual shell-like argument list, rather than a semicolon-separated list (CMake's internal stringification mechanism for lists). Apart from being a little easier to read, this also works directly with the response file support in swiftc itself now (not depending on utils/line-directive).
(It's still not quite enough to expand on a command-line, though, since that will escape the quotes. The 'sed' command can get around that:
$(sed "s/'//g" foo.txt).)