Re: [Development] OS X plugin naming bug

2014-11-22 Thread Hanspeter Niederstrasser
On 11/18/2014 2:18 PM, Stephen Kelly wrote: > Hanspeter Niederstrasser wrote: >> I have not been able to find the code that generates the >> .cmake files to figure out why it is not honoring the file extension >> change. > > Here they are: > > qtbase/mkspecs/features/create_cmake.prf > qtbase/m

Re: [Development] OS X plugin naming bug

2014-11-18 Thread Stephen Kelly
Hanspeter Niederstrasser wrote: > I have not been able to find the code that generates the > .cmake files to figure out why it is not honoring the file extension > change. Here they are: qtbase/mkspecs/features/create_cmake.prf qtbase/mkspecs/features/data/cmake/* Thanks, Steve. __

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Thiago Macieira
On Friday 14 November 2014 13:49:25 Hanspeter Niederstrasser wrote: > > I don't understand your answer. > > > > You're saying that nothing has linked to the Qt plugins. Well, of course. > > By > > definition, a plugin is something you don't link to. > > Right. I guess I was just restating the obv

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Hanspeter Niederstrasser
On Fri, November 14, 2014 1:01 pm, Thiago Macieira wrote: > On Friday 14 November 2014 12:43:40 Hanspeter Niederstrasser wrote: >> On Fri, November 14, 2014 9:58 am, Thiago Macieira wrote: >> > 2) User applications have plugins of their own >> >> I don't think this would impact an end user app wit

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Thiago Macieira
On Friday 14 November 2014 12:43:40 Hanspeter Niederstrasser wrote: > On Fri, November 14, 2014 9:58 am, Thiago Macieira wrote: > > 2) User applications have plugins of their own > > I don't think this would impact an end user app with its own plugins that > also uses Qt5 plugins. The application

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Hanspeter Niederstrasser
On Fri, November 14, 2014 9:58 am, Thiago Macieira wrote: > 2) User applications have plugins of their own I don't think this would impact an end user app with its own plugins that also uses Qt5 plugins. The application would have been compiled with the paths for dlopen to search for its own plug

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Thiago Macieira
On Friday 14 November 2014 07:58:43 Jake Petroules wrote: > Yeah, Qt plugins should absolutely be packaged as bundles (loadable > modules). I’ve mentioned this before; I think this is a good next aim for > 5.5. Shouldn’t be much more work than changing the extension from .dylib to > .bundle and add

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Jake Petroules
> On Nov 14, 2014, at 7:44 AM, Morten Johan Sørvig > wrote: > >> >> On 14 Nov 2014, at 02:58, Hanspeter Niederstrasser >> wrote: >> >> On OS X, Qt is building plugins as dynamic libraries, instead of >> bundles, which is the more appropriate format for the platform. This was >> filed as Q

Re: [Development] OS X plugin naming bug

2014-11-14 Thread Morten Johan Sørvig
> On 14 Nov 2014, at 02:58, Hanspeter Niederstrasser > wrote: > > On OS X, Qt is building plugins as dynamic libraries, instead of > bundles, which is the more appropriate format for the platform. This was > filed as QTBUG 2227 six years ago, but it was marked as closed without > any work do

[Development] OS X plugin naming bug

2014-11-14 Thread Hanspeter Niederstrasser
On OS X, Qt is building plugins as dynamic libraries, instead of bundles, which is the more appropriate format for the platform. This was filed as QTBUG 2227 six years ago, but it was marked as closed without any work done on it, even though there was a patch listed. For the Fink package manag