[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hackers] MSYS2/Mingw primer

Dave Hart wrote:

On Thu, Mar 16, 2023 at 11:40 AM Martin Burnicki <burnicki@xxxxxxx> wrote:

Just for the case that you want to give MSYS2/Mingw a try: I've put some
information together how to get started:
https://wiki.burnicki.net/miscellaneous_tips:20_software_development:msys2_mingw_notes

I've also just recently started to use it, and I'm very happy for what
I've seen so far. You can easily use things like git and ssh from within
the bash shells provided by the build environment.


I completely understand your desire to use the development environment
you're most familiar with for building the NTP distribution.  Having
an environment that has or lets you add your familiar POSIX-style
tools is clearly a win, and as you noted the resulting binaries can be
used even outside the mingw environment.
I've also been working with Microsoft build environments for user space programs and kernel drivers for more than 20 years, so I saw how much easier it is to maintain a project that uses makefiles than a project that uses any of the Microsoft toolchains. And yes, I know you're biased. ;-) 


If it would be possible to build NTP for Windows using this toolchain,
we could probably avoid a lot of the hassle we have due to supporting
different VS versions with their various project files.


I suspect the hassle of filling in the specifics we need for Windows
like the time stuff I mentioned earlier, and the service control
manager integration) will be more than the hassle of supporting
different VS versions.
Sorry, but I disagree here. These features are just based on calling some Windows API calls, which you can also do from an application that is compiled with a different toolchail. 


We may well get it down to two supported
Visual Studio ports/winnt/vs* directories (vs2015 to build
XP-compatible binaries, and vs2022 for a newer, more C11-compliant
compiler).


I'm assuming that it would even be possible to integrate Windows support
into NTP's autoconf/automake stuff and let it detect the Windows target
system, but as mentioned earlier, I'm not familiar with that auto stuff,
so I'm not sure whether this makes sense, or whether to just create a
set of makefiles once for each of the NTP programs.

On the other hand, unlike Unix-like systems, Windows is a well-known
target, so it may be possible to just set up a couple of static
makefiles which don't have to be created by autoconf/automake.


Right, autotools isn't really a problem-solver for the Windows target.
Our approach is mostly Windows as a single target with common
prerequisites (all compatible refclocks, openssl).
Right. I think the biggest challenge here is openSSL, i.e. which version to use, how to specifify the directories where the header files and the import libraries are located, etc.
In the past we have specified these directories via environment variables that were reference in the VS project files, and I think this can be done in the same way with a plain makefile. 


There are of
course 32-bit and 64-bit targets, not strictly necessary as nothing in
ntpd requires 64-bit, but it does eliminate some runtime translation
overhead on 64-bit systems.  When dealing with newer capabilities in
Windows ntpd adjusts at runtime, rather than build time.  For example,
the more-precise Windows native clock in Windows 8 and later is
detected via runtime linking and used if available.
I don't think this is a show stopper for MSYS2/MinGW, as I tried to explain in an earlier email. 


I think it's also worth noting that the VS development environment is
extremely useful to me.
I can only quote what your wrote above for me, which seems to apply to you, too: 


I completely understand your desire to use the development
environment you're most familiar with for building the NTP
distribution.

;-)



I'm able to use its IDE to speed code
exploration and changes, such as finding all references to a variable
or function, quickly jumping to a function implementation from code
that calls it, or expanding a macro by hovering over code that uses
it.  The debugger is an efficiency win for me as well, making it quick
and easy to set code or data breakpoints.  Obviously some code is
Unix-specific so I need to use Unix systems and tools as well, but for
common code the IDE is preferable for me.
I didn't want you to drop support for Visual Studio. However, if we have *one* additional tool chain like MSYS2/MinGW which is not so depending on IDE and Windows version, this could be helpful for those who just build the NTP package, and might reduce the number of VS versions that need to be maintained. 

Martin