Bug 395651

How do you know it expected it there?

Docs imply it checks both:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_manifests

and it works here on my x64 system.

(In reply to David Edmundson from comment #1)
> How do you know it expected it there?
> 
> Docs imply it checks both:
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_manifests
> 
> and it works here on my x64 system.

How do I know Firefox is expecting it in /usr/lib64?

It does not work in /usr/lib. After installing the Plasma Integration Add-on from the Firefox add-ons site, I got this error:

‘Plasma Integration Error Failed to connect to the native host. Make sure the ‘plasma-browser-integration’ package is installed.’

1. The plasma-browser-integration package is installed.
2. I noticed that the file org.kde.plasma.browser_integration.json’ was located in /usr/lib/.
3. In my distributions 64-bit libraries are installed in /usr/lib64/
4. After placing org.kde.plasma.browser_integration.json in /usr/lib64/mozilla/native-messaging-hosts/ it works. 
5. Thus Firefox is expecting it to be in usr/lib64/mozilla/native-messaging-hosts/

Using the cmake KDE_INSTALL_LIBDIR variable ensures placement of the file is in the correct place for the system it was built for. 

As a side note, it was noted by another Slackware user that that file org.kde.plasma.browser_integration.json must be in /etc/chromium/native-messaging-hosts/ not in /etc/kde/chromium/native-messaging-hosts/. I do not use Chromium so can't verify that but thought I'd mention it.

That would break Debian and Debian-based targets.

See the discussion on https://phabricator.kde.org/D13056.

For this reason it's not hardcoded but a configurable parameter.

As I stated in my report. It is hard coded in CMakeLists.txt in the 5.13.0 tarball, just checked github and is the same.

Line 48: 
set(MOZILLA_DIR "${CMAKE_INSTALL_PREFIX}/lib/mozilla" CACHE STRING "Mozilla directory")

I read that discussion, the way that patch is written, it would break Slackware too by removing an essential variable CMAKE_INSTALL_PREFIX On Slackware CMAKE_INSTALL_PREFIX=/usr is passed to cmake Which would end up being /lib/mozzila not /usr/lib/mozilla.

My patch simply uses the base CMAKE_INSTALL_PREFIX (normally /usr) and adds
KDE_INSTALL_LIBDIR which should be /lib<qual> qual being lib or lib64 as the build option passed to cmake.
End up with /usr/lib64/mozilla on a Slackware64 system and /usr/lib/mozilla on a Slackware system (32-bit)

Supplementing my last comment to make it clearer

I read that discussion, the way that patch is written, it would break Slackware too by removing an essential variable CMAKE_INSTALL_PREFIX

On Slackware the directory would end up being /lib/mozzila not /usr/lib/mozilla.

set(SomeVariable)

is not creating something hardcoded, rather the exact opposite. It's creating a variable that can be set from outside with a default.

i.e
cmake -DMOZILLA_DIR=/tmp/cheese  or set with ccmake/cmake-gui 


(it's irrelevant to the point about whether the default should be lib or lib64, but quite important to clarify)

(In reply to David Edmundson from comment #6)
> set(SomeVariable)
> 
> is not creating something hardcoded, rather the exact opposite. It's
> creating a variable that can be set from outside with a default.
> 
> i.e
> cmake -DMOZILLA_DIR=/tmp/cheese  or set with ccmake/cmake-gui 
> 
> 
> (it's irrelevant to the point about whether the default should be lib or
> lib64, but quite important to clarify)

It is creating something hard coded. 

set(MOZILLA_DIR "${CMAKE_INSTALL_PREFIX}/lib/mozilla" CACHE STRING "Mozilla directory")

'/lib/mozilla' IS hard coded. So if CMAKE_INSTALL_PREFIX=/usr then
MOZILLA_DIR becomes '/usr/lib/mozilla'

I am proposing to make use of KDE_INSTALL_LIBDIR to set from the outside. So that MOZILLA_DIR can be set to /usr/lib64/mozilla or /usr/lib/mozilla or /usr/<value>/mozilla

set(MOZILLA_DIR "${CMAKE_INSTALL_PREFIX}${KDE_INSTALL_LIBDIR}/mozilla" CACHE STRING "Mozilla directory")

cmake -DCMAKE_INSTALL_PREFIX=/usr -DKDE_INSTALL_LIBDIR=/lib64

results in MOZILLA_DIR set to '/usr/lib64/mozilla'

KDE_INSTALL_LIBDIR could also be CMAKE_INSTALL_LIBDIR

cmake -D MOZILLA_DIR=/opt/asdf results in

 * MOZILLA_DIR, Mozilla directory is '/opt/asdf'

which means it works as expected.

(In reply to Fabian Vogt from comment #8)
> cmake -D MOZILLA_DIR=/opt/asdf results in
> 
>  * MOZILLA_DIR, Mozilla directory is '/opt/asdf'
> 
> which means it works as expected.

As you expected.

Would not call that a standard method. Most Plasma cmakes use KDE_INSTALL_LIBDIR, CMAKE_INSTALL_LIBDIR or LIB_SUFFIX. The first two are accepted parameters with the cmake of plasma-browser-integration. That is what should be expected. 

You are giving the user the option of CMAKE_INSTALL_PREFIX but not the option of  CMAKE_INSTALL_LIBDIR which most cmakes do. By having to set MOZILLA_DIR directly one looses both options. Yes I could have just simply set the MOZZILA_DIR directly to start with and not file this bug which I consider valid, resolved. I filed this because you hard coded a location which on some distribution does not work.

It's not possible to do it in a way which works everywhere.

(In reply to Fabian Vogt from comment #10)
> It's not possible to do it in a way which works everywhere.

Why is that? My suggestion make virtually every aspect of this variable user configurable except for the 'mozzila' part.

(In reply to Fabian Vogt from comment #10)
> It's not possible to do it in a way which works everywhere.

You know I was hoping for a follow up on this. Always trying to learn new things. 

Would be kind of cool to know a reason for "not possible to do it in a way which works everywhere" since my proposal allows the user to customize all aspects of the MOZILLA_DIR variable except the mozilla directory part.

(In reply to Chris from comment #12)
> (In reply to Fabian Vogt from comment #10)
> > It's not possible to do it in a way which works everywhere.
> 
> You know I was hoping for a follow up on this. Always trying to learn new
> things. 
> 
> Would be kind of cool to know a reason for "not possible to do it in a way
> which works everywhere" since my proposal allows the user to customize all
> aspects of the MOZILLA_DIR variable except the mozilla directory part.

That's already possible now.

(In reply to Fabian Vogt from comment #13)
> (In reply to Chris from comment #12)
> > (In reply to Fabian Vogt from comment #10)
> > > It's not possible to do it in a way which works everywhere.
> > 
> > You know I was hoping for a follow up on this. Always trying to learn new
> > things. 
> > 
> > Would be kind of cool to know a reason for "not possible to do it in a way
> > which works everywhere" since my proposal allows the user to customize all
> > aspects of the MOZILLA_DIR variable except the mozilla directory part.
> 
> That's already possible now.

Sigh, I realize that. I like to know what was wrong with my approach as a possible solution. I can understand that 'mozilla/native-messaging-hosts/' should probably be static, but due to some distributions using the alternate locations under the FHS for libraries it just made sense to me to add a commonly used cmake variable to set the library<suffix> location vice using the MOZILLA_DIR variable. Thanks.