basedir spec and plugins
Brian J. Tarricone
bjt23 at cornell.edu
Tue Jun 30 15:09:36 PDT 2009
On 2009/06/30 14:11, Thiago Macieira wrote:
> Simon McVittie wrote:
>> On Tue, 30 Jun 2009 at 04:08:26 -0300, Thiago Macieira wrote:
>>> We'll need an architecture key, which is composed by the host OS plus
>>> at least the processor main type.
>> Multiarch http://lackof.org/taggart/hacking/multiarch/ addresses this by
>> taking the CPU and OS (or CPU and kernel+OS) from
>> config.guess/config.sub, i.e.
>> `/usr/share/misc/config.guess | cut -d - -f 1,3-`:
>> i386-linux-gnu, x86_64-linux-gnu
> What's the "gnu" part good for? The important thing here is the kernel ABI
> and the processor. (This is not a discussion of "Linux" vs "GNU/Linux")
> Unless there's a i386-linux-uclibc that we have to consider...
Well, yes, that's what 'gnu' here means: glibc. Might we come into a
case where one system has the app compiled against glibc, and another
system has the app compiled against another libc? Maybe, but again
unlikely. (That actually would be a problem, since the main app would
link against one libc, and the plugin linking against the other, with
unpredictable symbol overriding going on.) How much do we care to
support this case?
Regardless, could still tack the C++ ABI on the end, whether or not you
include the libc type.
> We can argue as well that we don't want to solve that problem either. If
> it works for the free operating systems (where GCC seems to be the rule),
> we can be happy.
There's certainly value to supporting other combinations, but I'm not so
sure about the cost of doing so. I'm less concerned about the naming of
the arch-specific dir (sure, throw all sorts of info in there if it's
necessary; it's just a mostly-user-invisible identifier anyway), but
worried about how apps on a single system that supports multiple arches
would deal with looking things up when XDG_LIB_HOME is set. But maybe
we can just punt in that case? Something like:
"XDG_LIB_HOME will default to $HOME/.local/lib/$ARCH_OS_ABI_STRING/.
Implementations which wish to use this default will need to detect the
machine architecture, operating system, and C++ ABI [etc.] at
compile-time. If XDG_LIB_HOME is set to a particular value, the
application shall use that value without regard to the arch-specific
directory. Users who do not wish to rely on the default should take
care to set this variable appropriately if they run applications on the
same machine that are compiled for different architecture/OS/C++-ABI
Or, we could go a different route and not define XDG_LIB_HOME at all, in
favor of something like this:
"XDG_LIBROOT_HOME [or some other name that distinguishes it] will
default to $HOME/.local/lib/. Implementations must append
$ARCH_OS_ABI_STRING to that value, which can usually be discovered at
This actually sounds like a decent route to take to me. The application
(or library) that actually knows what arch/OS/ABI/toaster it was
compiled for, can decide the arch-specific string, and the spec only
needs to define the format of the string and provide examples. A
user/sysadmin that wishes to set this won't have to worry about
More information about the xdg