Bug 395651 - CMakeLists.txt MOZILLA_DIR hard coded /lib/mozilla
Summary: CMakeLists.txt MOZILLA_DIR hard coded /lib/mozilla
Status: RESOLVED NOT A BUG
Alias: None
Product: plasma-browser-integration
Classification: Unclassified
Component: Firefox (show other bugs)
Version: unspecified
Platform: Slackware Packages Linux
: NOR major
Target Milestone: ---
Assignee: Kai Uwe Broulik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-20 13:19 UTC by Chris
Modified: 2018-07-07 09:42 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch set correct libdir path (774 bytes, patch)
2018-06-20 13:19 UTC, Chris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris 2018-06-20 13:19:18 UTC
Created attachment 113461 [details]
Patch set correct libdir path

Slackware64-current
Firefox 60.0.2 (64-bit)
KDE Plasma 5.13.0
Qt: 5.11.0
KDE Frameworks: 5.47.0
Plasma-browser-integration 5.13.0

When compiling from the source make install places org.kde.plasma.browser_integration.json in usr/lib/mozilla/native-messaging-hosts/  on a x64_64 system Firefox is expecting to find this file in usr/lib64/mozilla/native-messaging-hosts/

This is because in CMakelists.txt line 48 is hard coded to /lib/mozilla
set(MOZILLA_DIR "${CMAKE_INSTALL_PREFIX}/lib/mozilla" CACHE STRING "Mozilla directory")


Suggested patch using the CMake variable KDE_INSTALL_LIBDIR to CMakeLists.txt is attached.

Chris
Comment 1 David Edmundson 2018-06-22 11:09:14 UTC
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.
Comment 2 Chris 2018-06-22 12:29:33 UTC
(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.
Comment 3 Fabian Vogt 2018-06-22 12:57:55 UTC
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.
Comment 4 Chris 2018-06-22 13:38:06 UTC
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)
Comment 5 Chris 2018-06-22 13:54:27 UTC
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.
Comment 6 David Edmundson 2018-06-22 15:11:08 UTC
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)
Comment 7 Chris 2018-06-22 16:08:06 UTC
(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
Comment 8 Fabian Vogt 2018-06-26 07:44:15 UTC
cmake -D MOZILLA_DIR=/opt/asdf results in

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

which means it works as expected.
Comment 9 Chris 2018-06-27 13:02:06 UTC
(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.
Comment 10 Fabian Vogt 2018-06-27 13:06:28 UTC
It's not possible to do it in a way which works everywhere.
Comment 11 Chris 2018-07-02 06:00:12 UTC
(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.
Comment 12 Chris 2018-07-07 07:00:39 UTC
(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.
Comment 13 Fabian Vogt 2018-07-07 07:59:03 UTC
(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.
Comment 14 Chris 2018-07-07 09:42:10 UTC
(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.