GNOME Bugzilla – Bug 733934
win32: improve the package installation dir lookup
Last modified: 2017-09-16 13:33:36 UTC
Modules like gedit have the main private library in root/lib/gedit, checking only for the parent whether it is lib or bin is not enough. What I do here is to iterate through the parents until I find lib or bin or the root in which case I just take the parent.
Created attachment 281975 [details] [review] win32: improve the package installation dir lookup
Review of attachment 281975 [details] [review]: Patch is OK.
Review of attachment 281975 [details] [review]: it would be nice to have a better commit message, to be honest, with examples of installation directories that would fail with the existing code. the code itself looks okay.
Created attachment 282135 [details] [review] win32: improve the package installation dir lookup As an example, the core of gedit is in a private library placed in %INSTALLDIR%/lib/gedit/libgedit.dll Before this patch we would get %INSTALLDIR%/lib/gedit as the installation package dir, while what we actually want is to get %INSTALLDIR%
Review of attachment 282135 [details] [review]: looks good to me.
Attachment 282135 [details] pushed as 786590f - win32: improve the package installation dir lookup
This commit should really have updated the docs. I created bug 739835 from the confusion it caused. The current docs explicitly go against all of this behavior and it has caused some strange behavior for some users naming a folder bin 5 directories up from the actual program (which is an odd use-case I admit). Current docs being: >If that directory's last component is "bin" or "lib", its parent directory is returned, otherwise the directory itself. >It thus makes sense to pass only the handle to a "public" DLL of a software package to this function, >as such DLLs typically are known to be installed in a "bin" or occasionally "lib" subfolder of the >installation folder. DLLs that are of the dynamically loaded module or plugin variety are often >located in more private locations deeper down in the tree, from which it is impossible for GLib to >deduce the root of the package installation.