basedir spec and plugins

[Thiago Macieira]

Brian J. Tarricone wrote:
>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.

We're not talking about the same app here. If we were, then the plugins 
would be placed in this application's specific directories and we wouldn't 
be having this discussion.

I believe we're talking here about generic application plugins, that can 
be used for all applications. I don't have a use-case for it (see my 
earlier emails on the thread), but it could happen in the future.

And, in any case, it could be the same app as well, if we consider that 
$HOME is often mounted from an NFS server. So it's not too far-fetched to 
imagine two different systems with two different builds sharing an NFS 
mount.

>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?

Well, then think of Solaris, where KDE does run on. And it can be compiled 
with both Sun CC and GCC. And they are binary incompatible.

Interestingly, in the HP-UXi on IA-64 case, the ABI is technically the 
same because that's the platform where GCC's current C++ ABI comes from: 
the Itanium C++ ABI. The HP C++ compiler uses it too. Of course, the 
problem still applies because the standard C++ libraries are different.

>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?

Those are the questions this thread is trying to answer.

>> 	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.

Good point. I was thinking of a SPARC 64-bit machine running 32-bit 
binaries, but of course those are the same as SPARC 32-bit binaries.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090630/2cdd19a1/attachment.pgp