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

Re: [hackers] MSYS2/Mingw primer



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.

> 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.  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).  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 think it's also worth noting that the VS development environment is
extremely useful to me.  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.

Dave Hart
-- 
This is hackers@xxxxxxxxxxxxx
Subscribe: hackers+subscribe@xxxxxxxxxxxxx
Unsubscribe: hackers+unsubscribe@xxxxxxxxxxxxx