basedir spec and plugins

[Brian J. Tarricone]

On 2009/06/30 00:08, Thiago Macieira wrote:

> What's more, to be suitable for C++, we may need to encode the C++ ABI for
> architectures where more than one C++ compiler are common (which is just
> about every platform except the free ones). But we can have that as a
> subtype.

Is this necessary?  Would you really expect someone to have two copies 
of the same app or library installed, each with a different C++ ABI 
used?  If not, then it's fine to keep plugins with different ABIs in the 
same directory.

Also note that we're talking about desktop use here.  That's the 'D' in 
XDG.  Who is going to have HPUX running on IA64 as a desktop machine AND 
want to do something ridiculous like have two copies of the same app 
installed, compiled with different C++ ABIs?

How would you set/determine this in the app when finding a default value 
of XDG_LIB_HOME?  What happens if XDG_LIB_HOME is set in the 
environment?  How does this get adjusted for any of the possible 
subtypes (32/64bit, diff C++ ABI, diff endianness) when you could have 
more than one available on the same machine during the same desktop session?

I think for XDG_CONFIG_HOME and XDG_CACHE_HOME at least, we assume that 
you set these at the beginning of your session and they stay that way, 
unchanged (aside from corner use cases or app debugging).  I suppose 
it's fine to have a different assumption for XDG_LIB_HOME, but it sounds 
a bit over-engineered to me for desktop use.

> 	x86-64-linux

x86_64-linux, actually...

> 	sparc-solaris-32 (subtypes g++ and CC)
> 	sparc-solaris-64 (subtypes g++ and CC)
> 	sparc-linux-32
> 	sparc-linux-64

Wouldn't you normally use sparc/sparc64 to make that distinction 
(similar to powerpc/powerpc64 or i386/x86_64)?  32-bit binaries running 
on a sparc64 CPU/kernel can be considered sparc-linux.

	-brian