feat: compiling using msys2 and mingw

[Kreijstal]

Yes, it's not as pretty as msvc, but it's open source tooling :/. I think this satisfies the immediate need, and if there are further changes I think they might be patchable.

Adding compatibility to use windmc.

@dgreatwood This is what I can muster up to. I know it's not pretty, but this is of course a short term solution. If there are big changes in the manifest, you can ping me and I'll try to adapt it, it should be less work. But here you can cross-compile from linux, that ain't bad right? LMK what you think.

I could also hook up a CI for msys2 compilation if desired.
fixes #1276

[Kreijstal]

I'll try to fix CI.

[dgreatwood]

Hi @Kreijstal -

Firstly, thanks so much for this effort! If I may so, I think it is quite promising.

May I try and describe your strategy? Please correct me if I have misunderstood:

1. You have produced pist_winlog.mc, which is an ".mc" version of pist_winlog.man. I guess you did this manually? Or if you used a tool, what did you use - is it something we could automate?
2. In pist_winlog_impl.cc, you create explicit functions (e.g. EventWritePSTCH_DEBUG_NL_AssumeEnabled) which in the mc.exe case are macros in the generated header file pist_winlog.h. Again, I presume you did this more or less by hand, but again LMK if you used a tool.

Initial questions:

1. Don't we need a header file that corresponds to pist_winlog_impl.cc, let's say pist_winlog_impl.h? Or could we make it a pure header file, pist_winlog_impl.h, inlining all the functions since they're all simple I think?
2. And wouldn't pist_winlog_impl.h need to be included in pist_syslog.cc instead of pist_winlog.h (which mc.exe generates) in the non-mc.exe case? I believe pist_winlog.h should not be in the build if mc.exe is not used.

More generally:

1. The script winscripts/gccsetup.ps1 will always find mc.exe and place it on the path, so perhaps we can add a "--nomcexe" option for gccsetup?
2. We could add tests to meson.build so an error is produced if pist_winlog.man is newer than pist_winlog.mc or pist_winlog_impl.h/.cc. WDYT?

Thanks again!

[Kreijstal]

Hi @Kreijstal -

Firstly, thanks so much for this effort! If I may so, I think it is quite promising.

May I try and describe your strategy? Please correct me if I have misunderstood:

1. You have produced pist_winlog.mc, which is an ".mc" version of pist_winlog.man. I guess you did this manually? Or if you used a tool, what did you use - is it something we could automate?
2. In pist_winlog_impl.cc, you create explicit functions (e.g. EventWritePSTCH_DEBUG_NL_AssumeEnabled) which in the mc.exe case are macros in the generated header file pist_winlog.h. Again, I presume you did this more or less by hand, but again LMK if you used a tool.

Initial questions:

1. Don't we need a header file that corresponds to pist_winlog_impl.cc, let's say pist_winlog_impl.h? Or could we make it a pure header file, pist_winlog_impl.h, inlining all the functions since they're all simple I think?
2. And wouldn't pist_winlog_impl.h need to be included in pist_syslog.cc instead of pist_winlog.h (which mc.exe generates) in the non-mc.exe case? I believe pist_winlog.h should not be in the build if mc.exe is not used.

More generally:

1. The script winscripts/gccsetup.ps1 will always find mc.exe and place it on the path, so perhaps we can add a "--nomcexe" option for gccsetup?
2. We could add tests to meson.build so an error is produced if pist_winlog.man is newer than pist_winlog.mc or pist_winlog_impl.h/.cc. WDYT?

Thanks again!

It was kind of manual, was it macros? I guess we can convert those to macros...too, what is the script gccsetup for? If you have mc.exe you should just use that no?

There is no tool that did this work automatically, but it is reasonable to think one could be written... This would aid mimgw operability! With other projects that use manifests as well! So I really like the idea, this was however something more short term..