Open mohawk2 opened 1 month ago
This is a general issue with Alien system installs. It's not unlike the case where people change their system perl and forget to update their locally built and installed XS modules.
Some sort of detection logic at module load time would be useful but is best implemented in Alien::Build itself.
App::af
will allow you to rebuild the package (even switch from system to share or back) manually, but I am hesitant to pull in the full Alien::Build
system at runtime. I think what could be reasonable is an opt-in either at the user or the module level that when it detects a failed system install and only then pull in the alienfile
and try to redetect or rebuild. Few challenges here, like the the runtime user might not have access to the share directory and won't be able to update the runtime configuration.
Another thing that might help here is some awareness of homebrew in the Alien::Build
core.
I think a good starting point would be to make the config get tested every time the installed Alien gets loaded, to see if (some of?) the stored directories/files/libraries still exist? If Alien::proj had said "I expected directory blah
to exist but it doesn't now", this would have been very easy to fix.
@plicease What do you think? I don't feel a need for A:B to know about Homebrew, though you may know better.
The configuration on installing this module captures the path of the system library at that moment.
Under Homebrew, when the version of (here) proj changes, the path does too, and the old one goes away. This leads to Alien::proj confidently loading and giving a
cflags
return value that then produces compile errors ("cannot find proj.h").Perhaps a system install should redo its system-detection every time it loads? @plicease Do you have a view on this? Is it something that all Aliens with a system install option need to take into account?