cps-org
Glob search order should be "specified"
Currently, Package Searching gives a list of paths and specifies the order in which each item should be searched. However, some items involve globs. We should document the order in which matching globs are searched, even if that order is "unspecified" or "implementation defined".
Note that CMake appears to use CMAKE_FIND_PACKAGE_SORT_ORDER and CMAKE_FIND_PACKAGE_SORT_DIRECTION to control this order; it would be helpful for CMake's implementation if whatever we specify is compatible with this.
I'd prefer if we have some sort of definition here. I have real concerns about difficulties in projects with multiple build systems getting different results because (for example) CMake sorts one way, and Meson sorts another. If we leave it unspecified, it would appreciate something like "currently unspecified. This may change in a future revision of the CPS spec".
For reference, Meson would probably want to uses whatever Python's glob.glob() does.
Meson would probably want to uses whatever Python's glob.glob() does.
Right; there are going to be potential implementation headaches if we specify a particular sorting order. I'm more inclined to leave it unspecified, but we should specify that it's unspecified. :slightly_smiling_face: (Similarly, I'm in the process of implementing this for CMake, with the most convenient implementation being to do the same as for .cmake files. Which... is unspecified order by default, consistent with what Python's glob.glob(...) is documented to do, and in both cases almost certainly means "whatever the underlying FS does".)
Discussion is always welcome, but this Issue exists firstly as a reminder to "fix" the documentation. (Since this has a normative impact, even if actual practice isn't affected, I'm considering it a "bug", not just editorial.)
This may change in a future revision of the CPS spec
As far as I'm concerned, it's always permissible to specify something that was previously unspecified, since the specified behavior will always be a subset of what the unspecified behavior permitted.
As far as I'm concerned, it's always permissible to specify something that was previously unspecified, since the specified behavior will always be a subset of what the unspecified behavior permitted.
Fair. My motivation is that language communicates to a reader "we know that leaving this unspecified could be problematic, but we're not going to specifying anything until we see it be a problem in practice"