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: nobody → mozilla
Status: NEW → ASSIGNED
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
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)
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.
Created attachment 187486 [details] [diff] [review] use nspr's version everytime
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.
Created attachment 187500 [details] [diff] [review] forgot mozilla-nspr.pc.in
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.
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 ;-)
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.