prefix in text files not detected in most recent build on Windows

[ryanvolz]

The most recent build is missing the info/has_prefix file with contents like:

"D:/bld/gobject-introspection_1572746954296/_h_env" text "Library/bin/g-ir-annotation-tool"
"D:/bld/gobject-introspection_1572746954296/_h_env" text "Library/bin/g-ir-doc-tool"
"D:/bld/gobject-introspection_1572746954296/_h_env" text "Library/bin/g-ir-scanner"
"D:/bld/gobject-introspection_1572746954296/_h_env" text "Library/lib/pkgconfig/gobject-introspection-1.0.pc"
"D:/bld/gobject-introspection_1572746954296/_h_env" text "Library/lib/pkgconfig/gobject-introspection-no-export-1.0.pc"

This is causing builds relying on gobject-introspection to fail because they try to call Python to run g-ir-scanner from a non-existent path. For example:

"D:/bld/gobject-introspection_1584559932217/_h_env/python.exe" "D:/bld/gdk-pixbuf_1584562698787/_h_env/Library/bin/g-ir-scanner" ...

is called for the new gdk-pixbuf Windows build (conda-forge/gdk-pixbuf-feedstock#19) but fails because the Python path points to the non-existent build directory from gobject-introspection.

This is clearly a bug with conda-build, but I'm putting this here for documentation purposes and as a reminder that gobject-introspection will need to be rebuilt to fix the prefix issue.

Likely related to conda/conda-build#3899.

[pkgw]

This might be a slightly different problem than conda/conda-build#3899 and friends. If I'm remembering correctly, I think that the prefix detection in conda-build on Windows works with Windows-style paths — C:\foo\bar — but not mixed-style ones — C:/foo/bar . I have some fuzzy memories of running into an issue with Unix-y software on Windows before.

If that's right, one can discuss whether conda-build should do prefix rewriting for both, but I bet that implementing that would be a fairly substantial undertaking. If my fuzzy memories are correct, I think I figured out some ways to get the relevant files to have Windows-style paths so that the prefix detection started succeeding.

[ryanvolz]

I also have hazy memories about prefix detection on Windows only working for paths of a certain style, so that might be it. However, I also know that building gobject-introspection locally with conda-build=3.18.11 has working prefix detection.

[pkgw]

OK, that's a pretty good piece of evidence.

[ryanvolz]

Well now, I tried just building this locally with conda-build=3.19.1 to see if there was anything that could be done by switching the prefix path style... and it just works, without any changes. So that's puzzling. It would be good to test the build again on the CI infrastructure.

[pkgw]

Hmm. Maybe it's more of an issue of personal machine vs. cloud, rather than conda-build version? From my reading of the logs it looks like the latest builds of g-i were built with 3.19.1 on Windows.

[ryanvolz]

I'm thinking that conda/conda-build#3903 did actually fix a prefix issue on Windows, so 3.18.12 and 3.19.0 are actually broken but 3.19.1 is fixed (at least locally). I did run into this locally with 3.19.0. It definitely could be that 3.19.1 is still broken on the cloud, or maybe there was a weird caching issue (3.19.1 was built and released through conda-forge shortly before the gobject-introspection builds happened).

[bollwyvl]

Also seeing this here: conda-forge/ipykernel-feedstock#55

have pinned to 3.18.11 for now, but the issue is a json file with a windows path. Oddly, pre-munging the path with Path.as_posix worked locally, but not in CF azure, even after re-creating my local env as similar as possible to the CI one.