Open LigH-de opened 1 year ago
Hi there!
I have never used MSYS myself, really. So I don't really know much about it. It's a GNU-ish toolset for Windows, right?
For vis_avs, only GCC-on-Linux and MSVC-on-Windows are currently available. I'd have to test an MSYS installation on Windows. Is MSYS the most common way to go to get GCC on Windows? Or is there a "pure" MinGW-w64-GCC/-Clang toolchain one could also use instead?
What is a "fully static DLL"? One with no further DLLs linked in? Or a .lib
/.a
static library archive? Because a DLL itself is dynamically linked by definition, no?
I'm not opposed to this, quite the opposite, but there's two prerequisites:
vis_avs
Winamp plugin has to become the libavs
library (i.e. #11 should be done). This will take some months!I am no developer, only a halfwit using automated build scripts, sometimes reporting issues with slightly founded experience. So I hope to provide at least a few breadcrumbs out of the thicket...
I have never used MSYS myself, really. So I don't really know much about it. It's a GNU-ish toolset for Windows, right?
MinGW is a "Minimal GNU for Windows", and MSYS2 provides a wholesome distribution as environment for software development with Unix like tools under Windows. It provides an own installer and package management (via pacman).
What is a "fully static DLL"? One with no further DLLs linked in?
That's what I mean: No dependencies to runtime DLLs specific to a cross compilation subsystem (what you often have with cygwin). I would exclude from this demand e.g. MS VC Runtime DLLs from Visual Studio builds as they are common and shared between a large number of applications, and are available on many Windows PCs already. I remember that MinGW GCC builds may use some older, basic versions of their shared functions as well (msvcrt.dll), so this is a common exception.
The media-autobuild suite, when compiling codecs for ffmpeg or as separate executables, takes care with specific configuration options, sometimes additional patches, to produce e.g. an ffmpeg.exe with no external dependencies (except you configure your desired selection of codecs with one that does not support static linking and is only available as dependent DLL, like openh264, or loads a DLL on demand when a specific function is used, like VapourSynth script support).
You can configure the media-autobuild suite to actually not do much, except keeping an MSYS2+MinGW environment up to date. This may be a quite convenient alternative to the default MSYS2 installer.
Thanks for the in-depth explanations.
I'll keep MSYS2 in mind, once libavs is ready. Right now it's of little use on Windows.
I have a media-autobuild suite installed, that is an MSYS2 (msys64) environment with both MinGW32 and MinGW64 cross-compilation subsystems available to compile ffmpeg and a variety of linked modules with GCC 12 or Clang, which keeps itself up to date automatically.
This also supports an interactive mintty shell for either MinGW32 or MinGW64. I believe I should be able to unpack a source archive of your project, or pull it from your git repository, and then use either configure/make or CMake in MinGW32 to prepare and run the compilation.
Could you please add build instructions for MSYS2 in Windows to your front page if you already support this workflow with a matching CMake generator? I guess it would look like in x265:
cmake -G "MSYS Makefiles"
etc.And a fully static DLL output would be optimal, if the project structure allows it.