[gdal-dev] Windows CI build times

[Idan Miara]

Just an innocent question...
How come GCC is not one of the tested compilers on Windows and it's the
only tested compiler for Linux?
Is GCC for Windows not in par with MSVC?

Idan

On Thu, 4 Jun 2020 at 01:41, Even Rouault <even.rouault at spatialys.com>
wrote:

> On lundi 20 avril 2020 20:16:41 CEST Howard Butler wrote:
>
> > > On Apr 16, 2020, at 7:46 PM, Mateusz Loskot <mateusz at loskot.net>
> wrote:
>
> > >
>
> > > On Fri, 17 Apr 2020 at 01:45, Mike Taves <mwtoews at gmail.com> wrote:
>
> > >> It seems that many projects have shifted from AppVeyor to AZP for
>
> > >> performance benefits.
>
> > >
>
> > > Or GitHub Actions, which is an incarnation of AzP.
>
> >
>
> > Having done both GitHub Actions and AzP, I think Actions has more
> convenient
>
> > expressiveness of job flow, a big win of integration with GitHub's API,
> and
>
> > large directory of user-contributed actions.
>
>
>
> https://github.com/OSGeo/gdal/pull/2648 has now a migration of the VS2019
> build to GitHub actions, which will improve response time by cutting half
> of the load on AppVeyor
>
>
>
> For anyone attempting similar migration, here are a few random points on
> which I stumbled upon:
>
> - git on GitHub actions has the default behaviour of git on Windows, that
> is it must have core.autocrlf=true or whatever makes git turn LF into CRLF
> on some files. Fix was to set core.autocrlf=false
>
> - powershell on GitHub actions exits as soon as a command in a script
> fails. Which is reasonable, but for some reason our GDAL appveyor
> powershell sequences don't like that, especially when used with the black
> magic exec() function we have in appveyor.yml that seems to be an emulation
> of the default Github action mode. Fix was to set $ErrorActionPreference =
> 'continue'
>
> - anectodical: "Install-PackageProvider NuGet -Force", whatever that does,
> failed on github actions, but that turned out to be unnecessary.
>
> (I now know at least I actively hate powershell)
>
>
>
> So on AppVeyor remains the VS 2015 build, since github actions doesn't
> offer this compiler. At some point we will probably be able to remove VS
> 2015 builds. The main reason for keeping it is that OSGeo4W still uses VS
> 2015 to build GDAL, but this is going to be updated to 2019 soon according
> to Jürgen.
>
>
>
> I've also migrated recently the Mac Travis-CI jobs, and all code quality
> checks into github actions. Was easier.
>
>
>
> I will probably defer on migrating more things, that is the remaining
> Linux Travis-CI jobs. From a discussion with @pyusr on IRC, one solution to
> consider, and that would make us mostly CI host independent, would be to
> use Docker builds instead of relying on the VM provided by the CI host. I
> haven't considered that more, but on the paper it seems interesting. He was
> pointing to
>
>
> https://github.com/tzickel/chunkedbuffer/blob/master/.github/workflows/test.yml
> + https://github.com/tzickel/chunkedbuffer/blob/master/Dockerfile.test as
> an example . One potential issue is that we have some Linux builds that
> start Docker containers for databases, so I'm not sure how that would
> interact with the build & tests being done in docker build. Would probably
> work by doing them as separate preliminary steps in a job.
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200625/6761b86d/attachment.html>