Build failure when python Anaconda is installed

[Mo_Al_]

Hello

The issue was raised here:

https://github.com/fltk-rs/fltk-rs/discussions/1340

And I think it's related to the issue described in coredev here:

https://groups.google.com/g/fltkcoredev/c/SVXKJrt6wNw/m/cbPR7CWhBwAJ

The gist of the CI issue was strawberry perl was installed and put in PATH, thus confusing CMake, which, at the offending version (3.25.0), also search for libs with the extension .a to link with the MSVC toolchain (mimicking Meson).

The issue here is that Anaconda also prepends itself to PATH apparently, causing CMake to prepend any $PATH/include to the include directories, causing compile failures (with the recent upstream update of vendored image libs) or link failure with the previous version of vendored image libs.

My question is if anyone knows a way to prevent such CMake confusion when strawberry perl or anaconda are in PATH without asking users to remove them from PATH?

Searching online it seems CMAKE_IGNORE_PREFIX_PATH doesn't really work when it comes to excluding include paths. 

[Albrecht Schlosser]

On 1/20/23 10:25 Mo_Al_ wrote:

Hello

The issue was raised here:

https://github.com/fltk-rs/fltk-rs/discussions/1340

And I think it's related to the issue described in coredev here:

https://groups.google.com/g/fltkcoredev/c/SVXKJrt6wNw/m/cbPR7CWhBwAJ

Yep, this relation seems to be correct.

You can see a long discussion in GitHub issue https://github.com/actions/runner-images/issues/6627

The gist of the CI issue was strawberry perl was installed and put in PATH, thus confusing CMake, which, at the offending version (3.25.0), also search for libs with the extension .a to link with the MSVC toolchain (mimicking Meson).

This has been fixed in CMake 3.25.1. Upgrading CMake is the best solution so far. This has also been done in the GitHub runner image (see link above).

The issue here is that Anaconda also prepends itself to PATH apparently, causing CMake to prepend any $PATH/include to the include directories, causing compile failures (with the recent upstream update of vendored image libs) or link failure with the previous version of vendored image libs.

I think you brought it to the point in your own reply:
https://github.com/fltk-rs/fltk-rs/discussions/1340#discussioncomment-4744815

My question is if anyone knows a way to prevent such CMake confusion when strawberry perl or anaconda are in PATH without asking users to remove them from PATH?

The first workaround I used in our Windows GitHub CI builds was to disable system libs (png, jpeg, zlib) and this works. But this is what the OP in your issue found out already. If I understand correctly, using `features = ["fltk-bundled"]` in fltk-rs would do this.

Searching online it seems CMAKE_IGNORE_PREFIX_PATH doesn't really work when it comes to excluding include paths.

As I wrote above, upgrading CMake to at least 3.25.1 circumvents the issue.

You may find more workarounds if you follow the GitHub runner issue I mentioned above, particularly https://github.com/actions/runner-images/issues/6627#issuecomment-1328214957 and following comments and the links given there. This would start a long investigation if you're really interested.

One more CMake flag was mentioned in this comment: CMAKE_IGNORE_PATH. However, I didn't pursue this further.

That all said, upgrading CMAke (or downgrading to an earlier version) is the best solution to prevent this issue. This doesn't solve the root cause though that a tool inserts itself into the Windows system PATH and causes trouble. IMHO this should be solved as well, but if you contact the maintainers: good luck!

HTH, Albrecht