If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

mozilla-*.pc requires identical NSPR version

RESOLVED FIXED

Status

()

Core
Build Config
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: wolfiR, Assigned: wolfiR)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

13 years ago
mozilla-js.pc 
mozilla-nss.pc
mozilla-xpcom.pc

do require 
 %MOZ_APP_NAME%-nspr = %MOZILLA_VERSION%
if --with-system-nspr is used as configure option.

The required version and name should be gathered from the system NSPR in that case.
Please also see bug #290726 where a nspr.pc file will be provided from NSPR itself.
(Assignee)

Comment 1

13 years ago
Created attachment 183999 [details] [diff] [review]
quickshot (not tested yet)
(Assignee)

Updated

13 years ago
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 2

13 years ago
Created attachment 184001 [details] [diff] [review]
second try

first patch had a typo and this one has been tested successfully.
Attachment #183999 - Attachment is obsolete: true
(Assignee)

Comment 3

13 years ago
Comment on attachment 184001 [details] [diff] [review]
second try

this one expects a nspr.pc file which will most likely introduced soon in nspr
(please see mentioned bug in above comment)
Attachment #184001 - Flags: review?(caillon)
The thing that concerns me is when we move to system nss/nspr, those should be
NSPR 4.x.  I'm wondering whether we should start including those versions as
advertised from Mozilla's NSPR as well.  NSPR version != Mozilla version, and
should not really be treated that way....

Comment 5

13 years ago
I think we can do that starting with Mozilla 1.8 and
Aviary 1.1.
I have a feeling that both Red Hat and Novell at the least want it to happen on
the branches, too.
(Assignee)

Comment 7

13 years ago
(In reply to comment #6)
> I have a feeling that both Red Hat and Novell at the least want it to happen on
> the branches, too.

Our internal development tree does already use NSPR's HEAD for all mozilla.org
projects. I'm hoping we get 4.6RTM for next release but for me it's not
mandatory that all needed changes are in the branches.
(Assignee)

Comment 8

13 years ago
I also think we shouldn't use MOZILLA_VERSION for NSPR at all and should start
at least with 1.8 to use correct numbering.
But the patch for that should be done by someone with more experience in
mozilla's build system than me. Maybe we should start with that, what we have now?

BTW: if we discuss that: mozilla's configure does check if NSPR >= 4.0.0.
I'm pretty sure that mozilla is not able to build against a version prior to
4.5.3 or 4.6.0?

Comment 9

13 years ago
Using NSPR and NSS version numbers (e.g., 4.6 and 3.9.5)
on the older Mozilla branches is fine by me, with the
caveat that some older Mozilla branches' NSPR and NSS
deviate from the official NSPR and NSS somewhat, so
the version numbers are just an approximation.

Starting with the Mozilla 1.8 and Aviary 1.1 releases
I plan to be more strict about staying as close to the
official NSPR and NSS as possible.  This is the reason
I suggested that we began with Mozilla 1.8/Aviary 1.1.
(Assignee)

Updated

12 years ago
Attachment #184001 - Flags: review?(caillon)
(Assignee)

Comment 10

12 years ago
Created attachment 187486 [details] [diff] [review]
use nspr's version everytime
Attachment #184001 - Attachment is obsolete: true
Attachment #187486 - Flags: review?(caillon)
(Assignee)

Comment 11

12 years ago
Please note that this patch (and this bug) is NSPR only for now.
The same should happen for NSS as soon as it is possible at all to build against
system-nss.
(Assignee)

Comment 12

12 years ago
Created attachment 187500 [details] [diff] [review]
forgot mozilla-nspr.pc.in
Attachment #187486 - Attachment is obsolete: true
Attachment #187500 - Flags: review?(caillon)
(Assignee)

Updated

12 years ago
Attachment #187486 - Flags: review?(caillon)
Comment on attachment 187500 [details] [diff] [review]
forgot mozilla-nspr.pc.in

At some point, I'd like to see us start using pkg-config rather than
nspr-config to get this information, but that's a separate bug.  I'm pretty
happy with this patch.

r=caillon
Attachment #187500 - Flags: review?(caillon) → review+
(Assignee)

Updated

12 years ago
Attachment #187500 - Flags: approval1.8b3?

Comment 14

12 years ago
Comment on attachment 187500 [details] [diff] [review]
forgot mozilla-nspr.pc.in

I have some questions.

In build/unix/Makefile.in, we have:

> ifdef MOZ_NATIVE_NSPR
...
>+NSPR_NAME=nspr
...
> else
...
>+NSPR_NAME=$(MOZ_APP_NAME)-nspr
...
> endif

Why can't we define NSPR_NAME to be "nspr" when MOZ_NATIVE_NSPR
is not defined?

>-	-e "s|%FULL_NSPR_CFLAGS%|$(FULL_NSPR_CFLAGS)|" > $@
>+	-e "s|%FULL_NSPR_CFLAGS%|$(FULL_NSPR_CFLAGS)|" \
>+	-e "s|%NSPR_NAME%|$(NSPR_NAME)|" \
>+	-e "s|%NSPR_VERSION%|$(NSPR_VERSION)|" > $@

I suggest that you break the trailing "> $@" into a separate
line to make it easier to add new -e lines in the future.

Updated

12 years ago
Attachment #187500 - Flags: approval1.8b3? → approval1.8b3+
(Assignee)

Comment 15

12 years ago
(In reply to comment #14)

> Why can't we define NSPR_NAME to be "nspr" when MOZ_NATIVE_NSPR
> is not defined?

We could. But I'm not sure because you could have a system NSPR installed
on the system together with a mozilla/xulrunner/firefox/whatever installed
NSPR version. Keeping the prefix would prevent namespace issues but has
the disadvantage that nspr-using applications do have to define which one
to choose. 
 
> >-	-e "s|%FULL_NSPR_CFLAGS%|$(FULL_NSPR_CFLAGS)|" > $@
> >+	-e "s|%FULL_NSPR_CFLAGS%|$(FULL_NSPR_CFLAGS)|" \
> >+	-e "s|%NSPR_NAME%|$(NSPR_NAME)|" \
> >+	-e "s|%NSPR_VERSION%|$(NSPR_VERSION)|" > $@
> 
> I suggest that you break the trailing "> $@" into a separate
> line to make it easier to add new -e lines in the future.

Thanks for the hint.
(Assignee)

Comment 16

12 years ago
Created attachment 187693 [details] [diff] [review]
alternative patch which use always nspr.pc

This patch will always create a nspr.pc file instead of MOZ_APP_NAME-nspr.pc.
There is the drawback that the file will conflict with a system installed NSPR.

But maybe that's a problem of the software packager.
With native NSPR the nspr.pc file should not be distributed but IMHO this is
also a problem of the software packager. The file gets created here in all
cases.
I'm still not sure which way to go. Someone else should decide ;-)
checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.