In configure.sh, there are four wenv options for windows as below:
     -c selects the Windows host and Cygwin (c) environment.
     -u selects the Windows host and Ubuntu under Windows 10 (u) environment.
     -g selects the Windows host and MinGW/MSYS environment.
     -n selects the Windows host and Windows native (n) environment.
Should we cover all of them in CI builds? I think  we could cover all of
them
if the infra could provides all the four windows enviroment.

There have been a lot of changes to the build system lately and I am sure that the Windows native build is not ready to use.  It will take some effort to use Windows native and there is, apparently, no users using the native build now.  There have been in the past and there will be in the future.  But I think we can wait on it.

You could omit Ubuntu under windows for now too.  It is just Ubuntu and really differs only in that you could be using a Windows native toolchain with Ubuntu.  Otherwise, it is the same as Ubuntu Linux so there is not very much to be gained in testing.

There is an issues of "return on investment" and "low hanging fruit."  Return on investment refers to how much benefit the testing provides based on the effort required to the testing. Some platforms should be tested but have a low return on investment.  But other platforms oare "low hanging fruit", that is, they are very easy to test and give us a great testing benefit.  Linux is low hanging fruit.

Cygwin and MSYS2 are the primary windows platforms.  They are essentially the same.  In fact, MSYS2 derives from Cygwin but with change to make it work better in Windows.  For example, it understands Windows paths as well as POSIX paths.  The other big difference is that it does not support any kind of symbolic links and it is especially intolerant of spaces in paths.

It would be better to substitute FreeBSD for macOS if MacOS not available
finally.
I'll raise an Infra jira later to see if FreeBSD available in Apache Infra.
You might need to keep the initial implementation simple and add more platforms later.
... And we could figure out how long the full build time.
According to the time, we could adjust build configs for PR check build if
necessary. Daily build should cover all the target builds any way.

I have an old, early generation I5 running Mint Linux that I do build testing on.  It takes many hours to build 419 configurations, almost 6 hours!  I should buy something faster!

It used to be a lot faster, but I upgraded the OS the toolchain recently and lost all of the performance.  No idea why.

Greg


Reply via email to