Closed
Bug 294747
Opened 19 years ago
Closed 19 years ago
mozilla-*.pc requires identical NSPR version
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: wolfiR, Assigned: wolfiR)
Details
Attachments
(2 files, 3 obsolete files)
3.95 KB,
patch
|
caillon
:
review+
|
Details | Diff | Splinter Review |
4.16 KB,
patch
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•19 years ago
|
||
first patch had a typo and this one has been tested successfully.
Attachment #183999 -
Attachment is obsolete: true
Assignee | ||
Comment 3•19 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)
Comment 4•19 years ago
|
||
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•19 years ago
|
||
I think we can do that starting with Mozilla 1.8 and Aviary 1.1.
Comment 6•19 years ago
|
||
I have a feeling that both Red Hat and Novell at the least want it to happen on the branches, too.
Assignee | ||
Comment 7•19 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•19 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•19 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•19 years ago
|
Attachment #184001 -
Flags: review?(caillon)
Assignee | ||
Comment 10•19 years ago
|
||
Attachment #184001 -
Attachment is obsolete: true
Attachment #187486 -
Flags: review?(caillon)
Assignee | ||
Comment 11•19 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•19 years ago
|
||
Attachment #187486 -
Attachment is obsolete: true
Attachment #187500 -
Flags: review?(caillon)
Assignee | ||
Updated•19 years ago
|
Attachment #187486 -
Flags: review?(caillon)
Comment 13•19 years ago
|
||
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•19 years ago
|
Attachment #187500 -
Flags: approval1.8b3?
Comment 14•19 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•19 years ago
|
Attachment #187500 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 15•19 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•19 years ago
|
||
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
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•