[haiku-development] find_directory()/find_path() and secondary architecture
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 05 Nov 2013 22:53:22 +0100
Howdy,
I've added an initial implementation of the discussed
find_path()/BPathFinder API. I wonder whether the functions, including
find_directory(), should take into account whether the call is made for
a secondary architecture and automatically add the respectively
subdirectory component where applicable. E.g. the gcc 4 add-ons on a gcc
2 hybrid Haiku are located in "<installation-location>/add-ons/x86". So,
if a gcc 4 program asks for the add-ons directory, this directory could
be returned instead of "<installation-location>/add-ons".
The advantage would be that code using this API to get paths for add-ons
or libraries would no longer have to mind whether it is compiled for the
primary or secondary architecture and append the subdirectory component
manually in the latter case.
A possible disadvantage could be that it would no longer be possible to
explicitly get the main directory this way -- e.g. in case one only
wants to look at/list/examine libraries/add-ons instead of loading them
into the own team.
The find_path*() functions have a flags parameter, so a flag
B_FIND_PATH_PRIMARY_ARCHITECTURE could be adding, that would force the
retrieval of the paths for the primary architecture. Since, at least
theoretically, there could be multiple secondary architectures, a flag
wouldn't suffice for the inverse behavior.
The general change would be relatively simple for find_directory(),
find_path(), and find_paths(), since the alternative paths would be
known at compile time already (depending on the primary or secondary
architecture libroot has been compiled for).
find_path_for_path() is a bit more complicated, since it retrieves the
path based off a specified file path, which doesn't even have to be an
executable, library, or add-on. And even if it is, determining the
architecture isn't entirely trivial/inexpensive. As a heuristic it could
be examined whether the path itself looks like it would point into some
secondary architecture subdirectory.
Alternatively a parameter could be added to explicitly specify the
secondary architecture (even for all functions except find_directory()).
Or, just as for find_path[s](), only the caller's architecture could be
considered.
And finally, the findpaths command line tool has similar issues.
Depending on the arguments it uses find_paths() or find_path_for_path()
respectively. Depending on the C API function decision it would either
always return the path(s) for the primary architecture or one would have
to specify the secondary architecture somehow. A simple method to do
that would be building it also for all secondary architectures, so that
the user could run e.g. findpaths-x86 when paths for the secondary
architecture x86 gcc 4 are desired. A command line argument would be
another option, but that would require a respective parameter in the C
function API.
Ideas and suggestions welcome.
CU, Ingo
Other related posts:
