Closed Bug 294747 Opened 19 years ago Closed 19 years ago

mozilla-*.pc requires identical NSPR version

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wolfiR, Assigned: wolfiR)

Details

Attachments

(2 files, 3 obsolete files)

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.
Attached patch quickshot (not tested yet) (obsolete) — Splinter Review
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attached patch second try (obsolete) — Splinter Review
first patch had a typo and this one has been tested successfully.
Attachment #183999 - Attachment is obsolete: true
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....
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.
(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.
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?
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.
Attachment #184001 - Flags: review?(caillon)
Attached patch use nspr's version everytime (obsolete) — Splinter Review
Attachment #184001 - Attachment is obsolete: true
Attachment #187486 - Flags: review?(caillon)
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.
Attachment #187486 - Attachment is obsolete: true
Attachment #187500 - Flags: review?(caillon)
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+
Attachment #187500 - Flags: approval1.8b3?
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.
Attachment #187500 - Flags: approval1.8b3? → approval1.8b3+
(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.
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
Closed: 19 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: