On Tue, 24 May 2022, Soft Works wrote:
-----Original Message-----
From: Martin Storsjö <mar...@martin.st>
Sent: Tuesday, May 24, 2022 1:26 PM
To: Soft Works <softwo...@hotmail.com>
Cc: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>;
Hendrik Leppkes <h.lepp...@gmail.com>
Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
long file names on Windows
On Tue, 24 May 2022, Soft Works wrote:
but Clang doesn't. (It's possible to use it
in Clang too if you enable it with -fms-extensions though.)
Is it possible to compile ffmpeg for Windows using Clang?
And if yes, does it even work without that flag?
(assuming it was introduced in order to be able to
compile Windows stuff).
Yes, it is possible to build it with Clang without any custom extra flags
to enable nondefault modes. In fact, it's tested continuously on FATE too:
http://fate.ffmpeg.org/history.cgi?slot=x86_64-mingw32-clang-trunk
Also for other architectures, e.g.:
http://fate.ffmpeg.org/history.cgi?slot=aarch64-mingw32-clang-trunk
OK, thanks for the pointers. I'm not sure whether it would be
acceptable to require this compilation flag for Windows builds?
I would very much prefer not to require adding -fms-extensions when
building with Clang - that option unlocks a lot of stuff that we generally
shouldn't be enabling.
Can you think of any other ideas?
Right now, mainly doing a #define ff_stat_struct which would require
updating the calling code. It's not ideal but worse things have been done
anyway (there's not that many stat calls).
I was exploring the idea of just redefining the struct, but e.g. "typedef
struct _stati64 win32_stat", but that only works when referring to the
type as "win32_stat", not "struct win32_stat". So that doesn't seem like a
good path forward either.
I'd prefer to slow down and think more about other alternatives here,
rather than rushing forward with adding -fms-extensions.
Also note that currently, we don't even have a proper automatic redirect
from stat to win32_stat, see the ifdef in libavformat/file.c. So this is
new development, or, raising the bar even further, in one sense.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
