Hi Even, Yes, I agree these times are way longer than they should take.
It looks like Howard was investigating AZP: https://github.com/OSGeo/PROJ/tree/azp how is that going? It seems that many projects have shifted from AppVeyor to AZP for performance benefits. As you mentioned, some of the dependencies could be built and cached, rather than using vcpkg. This is a bit more complicated, since each of the components are built differently. Another suggestion is to use a Ninja CMake generator (-GNinja), which is available with AppVeyor. On Fri, 17 Apr 2020 at 11:17, Even Rouault <even.roua...@spatialys.com> wrote: > > Hi, > > I've been a bit frustrated lately by the time spent on the GDAL AppVeyor CI > builds: roughly 50 minutes for each of the two configs we test, VS 2017 x86 > and VS 2015 x64, which can cause huge delays in case of busy days with many > pull requests etc. (those delays also impact PROJ since the limitation to one > simultaneous build is for the whole OSGeo GitHub organization) > > The immediate solution would be to just test VS 2017 x64 to cut that time > down and drop VS2015 and x64 testing. However as strange as it sounds, there > are still people using x86 builds... > I guess porting to Azure Pipelines (which we already use to refresh gdal.org) > could be a solution as well, since apparently they have a 10 concurrent job > limit ( according to > https://docs.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops > ) > > A ccache type of builds could also help since we rarely change headers. I > believe I tried to investigate that in the past but didn't find anything > really working. > > If someone is looking for ideas for contribution... _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
