Harlan Stenn wrote:
On 3/14/2023 2:27 AM, Martin Burnicki wrote:
[...]
It would be great when we could simply use something like MSYS2/Mingw to build the Windows version of the binaries.I don't do any development on Windows, and the good news is several/many other NTP developers who do and are good at Windows development.
Development for Windows is one thing, and which toolchain to use is another one. ;-)
My original goal was that maybe 'configure' could be run in a Cygwin environment, and that would give us the build tools I'm used to using. And folks who actually do Windows builds said that Cygwin is not a generally useful build environment for Windows executables.But this is just my understanding, and others can say better.
It's been a long time since I tried something with Cygwin. IIRC, its main disadvantage was that you had to have some cygwin-specific libraries available, not even to build a binary, but even if you tried to run the binary on a different machine.
Quite some time ago I started to use MSYS2/Mingw, which provides a full-featured Unix-like environment with a comfortable package management, which lets you easily install the usual build tolls including GNU make, gcc, clang, etc.
You can easily build native 32 or 64 bit Windows binaries (standard .exe files) using these tools, in a way that you don't need any cygwin-like runtime when executed on another machine where MSYS2/Mingw is not installed.
A big advantage is IMO that you can use standard GNU makefiles like on Unix machines, which are IMO very much easier to maintain than the different Visual Studio project files. The VS projects files are not even compatible across different VS versions, and have many settings duplicated for the different targets (Win32/Release, Win32/Debug, Win64/Release, Win64/Debug), so if you change a setting (e.g. an include search path), you have to very much care that the change becomes effective for *each* target, and not only for the target you have accidentally currently selected.
AFAIK the MSYS2/Mingw build environment also provides packages for autoconf, automake, etc., but I've never used these myself, not even on Linux, and I'm not familiar with these.
[...]
It would be good if a repo with 4.2.8p15 plus the collected changes would be available, so that everybody could easily keep track of the changes, and make commits based on the latest pre-release version, like it's usual today e.g. with git repos.We're working on that.
I know. For a very long time.
And it will be "more" than the STAGED changes, because security bugs are embargoed until the public release. But it will be "more" than what's there now.
I wasn't talking about security bug, but normal enhancements or new features.
If I can create and submit commits that already account for changes from other developers, the resulting code history becomes much cĺeaner and requires less manual merging as if everybody makes his own changes based on the same stable version that has been release quite some years ago.
For example, I've done some cleanup in the source code of 4.2.8p15, e.g. added an .editorconfig file and removed trailing spaces from many files. It doesn't make much sense to commit these changes, though, if some other folks have changed some files so you had to do a manual merge just to remove trailing spaces.Are your patches in a repo that I can merge?
My patches are currently in a local git repo, and for some changes it