[PATCH] D122335: [clang] Emit crash reproduction as a single tar file

Wed Mar 23 12:19:37 PDT 2022

erichkeane added a comment.

In D122335#3403453 <https://reviews.llvm.org/D122335#3403453>, @aaron.ballman wrote:

> In D122335#3403357 <https://reviews.llvm.org/D122335#3403357>, @erichkeane wrote:
>
>> In D122335#3403305 <https://reviews.llvm.org/D122335#3403305>, @aaron.ballman wrote:
>>
>>> In D122335#3403283 <https://reviews.llvm.org/D122335#3403283>, @abrachet wrote:
>>>
>>>> In D122335#3403281 <https://reviews.llvm.org/D122335#3403281>, @hubert.reinterpretcast wrote:
>>>>
>>>>> For users on Windows, would this cause extra trouble if they wanted to see what was included?
>>>>
>>>> Is `tar(1)` not available on Windows?
>>>
>>> It's available on Windows 10 and later by default, but otherwise .zip is the native archive format on Windows.
>>
>> We DO support older versions of Windows (Windows Server 2003 is still quite popular!), so presumably this requirement wouldn't be particularly acceptable.
>
> My feeling is: we have a TAR file writer, we don't have a ZIP file writer. While it'd be nice for us to produce zip files as those are more widely supported on all the platforms Clang runs on, it's a pretty heavy lift for this feature, especially given that newer versions of Windows come with a sufficiently useful tar program to handle them. So I'm fine with us producing TAR files -- if we decide to add support for ZIP in the future, we can allow the user to pick via a command line flag (or we could pick based on the host platform) and we can set the default behavior of Clang with a CMake flag.

Ah! I took the tests using 'tar' directly to mean we were offloading this work to 'tar', not that we had our own implementation of 'tar'.  In that case, I am ok with that as well; the burden is only on compiler-engineers to have a copy of 'tar' on their windows machine which is a requirement I'm OK with making.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122335/new/

https://reviews.llvm.org/D122335