Bug 80380 - pkg->path_position incorrect if previous directory-reading fails
Summary: pkg->path_position incorrect if previous directory-reading fails
Status: RESOLVED FIXED
Alias: None
Product: pkg-config
Classification: Unclassified
Component: src (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pkg-config
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-23 08:13 UTC by Daniel Macks
Modified: 2014-11-12 15:46 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Bump scanned_dir_count even if dir cannot be read (842 bytes, patch)
2014-06-23 08:30 UTC, Daniel Macks
Details | Splinter Review

Description Daniel Macks 2014-06-23 08:13:20 UTC
Package_.path_position is a numerical value corresponding to where its .pc file was found in the search_dirs list of directories that were searched. However, this number only tracks among directories that were actually able to be read. If a directory is skipped as unreadable, .path_postion no longer corresponds to the correct location in search_dirs. It's confusing when trying to debug:

$ PKG_CONFIG_PATH=/nosuch1:/nosuch2:/dir-with-foo.pc
$ pkg-config --debug foo
[...]
Path position of 'foo' is 1

even though foo is actually in the third directory specified. If ever someone wanted to extend 

Right now, it seems this value is used solely for sorting, to determine which of several pkg entries was found earlier in search_dirs. And one can use Package_.pcfiledir to look up the directory directly if that's what one wants to know. But if someone is extending the use of this value for some other purpose, it seems like broken behavior.
Comment 1 Daniel Macks 2014-06-23 08:30:18 UTC
Created attachment 101560 [details] [review]
Bump scanned_dir_count even if dir cannot be read

My previous test case now gives:

Path position of 'foo' is 3

This patch also adds the path_position to the --debug output to help keep track of the progress through the directory list.
Comment 2 Dan Nicholson 2014-11-12 15:46:16 UTC
Applied in a4ef355. Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.