[ninsbl]

Should be backported to the release branch.

[ninsbl]

The build still fails. It probably needs to be adjusted from here: #136

[hellik]

Have a look here #1561

[hellik]

We need to adapt our building scripts to updated dependencies in OSGeo4W v2

[ninsbl]

We need to adapt our building scripts to updated dependencies in OSGeo4W v2

@hellik build for the tests configures now. But compilation of esp. display modules throws errors. FFTW seems to be missing from OSGeo4W v2. Did I overlook something, @jef-n, if not could it be added?

Should test-builds and build for packaging (e.g. with regards to configure options and underlying libraries) be unified?

[jef-n]

https://github.com/jef-n/OSGeo4W/blob/master/src/grass/osgeo4w/package.sh builds with fftw from mingw.

[hellik]

Should test-builds and build for packaging (e.g. with regards to configure options and underlying libraries) be unified?

yes, as both are based upon the OSGeo4W environment. @landam

[ninsbl]

https://github.com/jef-n/OSGeo4W/blob/master/src/grass/osgeo4w/package.sh builds with fftw from mingw.

Thanks @jef-n very much appreciated!

I see you have some patches in https://github.com/jef-n/OSGeo4W/blob/master/src/grass/osgeo4w/patch

Those should probably be incorporated upstream?
The font issue in the cairo driver for example breaks the workflow-build also here... @nilason, would you mind having a look at lib/cairodriver/text.c?

Other changes are in:

• lib/gis/gisinit.c
• mswindows/env.bat
• mswindows/osgeo4w/env.bat.tmpl
• mswindows/osgeo4w/package.sh
• mswindows/osgeo4w/postinstall.bat
• gui/wxpython/wxgui.py

With the changes included upstream, would the best approach be to separate packaging from build, so the build part can be directly used in GH workflows? So we do not have to maintain .github\workflows\build_osgeo4w.sh in addition to mswindows/osgeo4w/package.sh

[jef-n]

Those should probably be incorporated upstream?

Yes. I just didn't want to start a fight about gisinit.c again - and maybe env.bat. I was already afraid that https://lists.osgeo.org/pipermail/osgeo4w-dev/2021-May/004251.html would already start it. ;)

With the changes included upstream, would the best approach be to separate packaging from build, so the build part can be directly used in GH workflows? So we do not have to maintain .github\workflows\build_osgeo4w.sh in addition to mswindows/osgeo4w/package.sh

I originally wanted to have workflows in the OSGeo4W repo - and also have updates to reverse dependencies trigger builds. But at least qgis (let alone qt - I didn't think about trying) needs too much disk space to build - and moreover takes ages to eventually run out of space. So I postponed that for "later". That's also why I didn't migrate all nightlies yet.

[nilason]

The font issue in the cairo driver for example breaks the workflow-build also here... @nilason, would you mind having a look at lib/cairodriver/text.c?

Attempt to address this at #1697.

[nilason]

Other changes are in:

• lib/gis/gisinit.c
• mswindows/env.bat
• mswindows/osgeo4w/env.bat.tmpl
• mswindows/osgeo4w/package.sh
• mswindows/osgeo4w/postinstall.bat
• gui/wxpython/wxgui.py

Re: wxpython/wxgui.py fix, this is reported with #1423, please see #1423 (comment) for better location for this.

[veroandreo]

Since the OSGeo4W Trac wiki download link points to v2, does it makes sense to have 8.0 there? Otherwise it won't get to the OSGeo4W users, no? It would be good to clarify this since it has milestone 8.2. Are we including this in 8.0? Do we want? Do we have to?

I'd like grass 8.0 to be in OSGeo4W please. Is that possible?

[ninsbl]

I'd like grass 8.0 to be in OSGeo4W please. Is that possible?

I am confident that @jef-n will get GRASS GIS 8 into OSGeo4W when the time comes. If there is anything I can contribute I am willing to do that, as mentioned by e-mail earlier.

This PR is however more for the MS Windows CI, which I hope can use the same build-setup as OSGeo4W in the future and that test become similarly comprehensive and successful as on Linux (some tests are currently platformdependent)...

I am about to separate out the different components in this PR so we can go ahead...

[wenzeslaus]

Thanks, @ninsbl. I'm still don't understand 100%.

This PR is however more for the MS Windows CI...

...more, but not only? I see some changes in mswindows dir.

...will get GRASS GIS 8 into OSGeo4W when the time comes.

That sounds great. I just want to be clear that nothing from here needs to go to 8.0, i.e., we create the branch for 8.0 and we don't backport anything from here and that will be fine (that's what milestone 8.2 suggests).

[neteler]

@ninsbl is this PR still relevant given that #2074 has been merged?

[ninsbl]

@ninsbl is this PR still relevant given that #2074 has been merged?

There are some changes here (mostly the last 4 commits) that have not been merged / addressed. These fix MS Windows specific CI issues and I would like to move them to a separate PR. Kept this ope just to not forget about it...

[ninsbl]

Bumping up milestone as 8.0.1 is due in two days, while this has not been part of RC1 and there has not been activity for some time.

[ninsbl]

The 8.0 releasebranch uses actually already V2:
https://github.com/OSGeo/grass/blob/releasebranch_8_0/.github/workflows/osgeo4w.yml

What remains from this PR is to address some specific test failures on MS Windows...

Renaming this PR and bumping up milestone....

[neteler]

@ninsbl Could you please git rebase this PR?

[wenzeslaus]

Are there any changes here which are still relevant? If yes, new separate PRs for each group of changes would be most appropriate at this point.

[ninsbl]

Outdated and replaced by: #2616 now. Closing this one.