Closed Bug 463075 Opened 11 years ago Closed 10 years ago

building xul app --with-libxul-sdk fails lacking nspr-config

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set

Tracking

(status1.9.1 .3-fixed)

RESOLVED FIXED
mozilla1.9.2b1
Tracking Status
status1.9.1 --- .3-fixed

People

(Reporter: ynvich, Assigned: karlt)

References

Details

Attachments

(3 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081104 Firefox/3.1b2pre
Build Identifier: trunk

configure.in is hardcoding $(DEPTH)/nsprpub/config/nspr-config into $(NSPR_CFLAGS) and $(NSPR_LIBS), but the file isn't created. Looks like nsprpub/configure isn't called anymore.

This is a regression against 1.9.0

Reproducible: Always




There maybe several solutions:
* actually create nspr-config in the tree in --with-libxul-sdk builds;
* ship nspr-config with sdk and use that one.
Regression from bug 462405.
Blocks: 462405
Status: UNCONFIRMED → NEW
Ever confirmed: true
In the xulrunner (SDK) side, can we copy nspr-config to dist/lib or someplace like that, and run it from there instead of directly from objdir/nsprpub/config ?
Copying nspr-config to dist/bin, and setting _USE_SYSTEM_NSPR=1 on "${with_libxul_sdk+set}" = set should be enough for uninstalled case.

In that case, nspr-config should get installed to $(libdir) on 'make install'.
No, we don't want to install NSPR as the system NSPR... the nspr-config should be isolated within sdkdir/lib
For reference, js-config is installed in dist/bin when building. 'make install' puts it into $(prefix)/bin
Attachment #376174 - Flags: review? → review?(ted.mielczarek)
(In reply to comment #4)
> No, we don't want to install NSPR as the system NSPR... the nspr-config should
> be isolated within sdkdir/lib

I don't think I fully understand this.
Would installing nspr-config into dist/bin be making it the system NSPR?
changes to Mozilla's configure.in to use nspr-config exported by attachment 376174 [details] [diff] [review].
Assignee: nobody → mozbugz
export needs to depend on $(TARGETS) for nsinstall.
Attachment #376174 - Attachment is obsolete: true
Attachment #377979 - Flags: review?(ted.mielczarek)
Attachment #376174 - Flags: review?(ted.mielczarek)
Do we want 1.9.1 to be able to build xul apps without --with-system-nspr?
(Or can xul apps be built without --with-libxul-sdk?)
Flags: blocking1.9.1?
Wouldn't block, but would take -- looks like an easy review for Ted.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
(In reply to comment #10)
> (Or can xul apps be built without --with-libxul-sdk?)

They can be built with:
ac_add_app_options <project> --with-libxul-sdk=<relative path to xulrunner objdir>/dist

in a multi-project build (which is what we're doing for Fennec). This bug is only about using a pre-built SDK, right?
(In reply to comment #12)
> They can be built with:
> ac_add_app_options <project> --with-libxul-sdk=<relative path to xulrunner
> objdir>/dist
> 
> in a multi-project build (which is what we're doing for Fennec).

"ac_add_app_options mobile --with-libxul-sdk=../xulrunner/dist" didn't work for me (with mk_add_options MOZ_BUILD_PROJECTS="xulrunner browser mobile").
Actually, it was probably "ac_add_app_options browser --with-libxul-sdk=../xulrunner/dist" that wasn't working for me.  I probably didn't get as far as mobile.  Maybe mobile doesn't use NSPR?
(In reply to comment #14)
> Maybe mobile doesn't use NSPR?

Indeed it doesn't (apart from on WinCE, which doesn't use nspr-config).
Attached patch rollup patch (obsolete) — Splinter Review
Just taken the liberty of rolling up those two patches since both are needed and adding a fix to stop nspr-config being packaged in Firefox on OSX.
Attachment #376177 - Attachment is obsolete: true
Attachment #377979 - Attachment is obsolete: true
Attachment #380194 - Flags: review?(ted.mielczarek)
Attachment #377979 - Flags: review?(ted.mielczarek)
Attachment #380194 - Flags: review?(ted.mielczarek) → review+
What's the process for getting (the NSPR part of these) changes into NSPR?
Comment on attachment 377979 [details] [diff] [review]
install nspr-config into $(dist_bindir)

Ted, this is identical to the NSPR part of the patch you reviewed and is what needs to land there.
Attachment #377979 - Attachment is obsolete: false
Attachment #377979 - Flags: review+
We can avoid needing to make changes to NSPR (which will take a while to get onto branch) by simply copying across nspr-config ourselves. The only new part of this patch is in config/nspr/Makefile.in
Attachment #385091 - Flags: review?(ted.mielczarek)
We've basically broken the documented ways to build XUL apps with our build system so any of those apps that include their own binary components can't update to 1.9.1 without this. The fix is pretty trivial build config stuff, any regressions should be almost immediately apparent.
Flags: blocking1.9.1.1?
Attachment #385091 - Flags: review?(ted.mielczarek) → review+
Pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/dc1c75480d85
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Attachment #385091 - Flags: approval1.9.1.1?
Comment on attachment 385091 [details] [diff] [review]
patch avoiding nspr
[Checkin: Comment 21 & 25]

This has been on trunk for nearly a week now with no issues, and it is the sort of thing that would completely break the build if it was wrong, so I think this is safe to take on branch
We won't *block* 1.9.1.1 on this, but may take the patch. It's more like that we'll block 1.9.1.2 on it and take it then, however.
Flags: wanted1.9.1.x+
Flags: blocking1.9.1.1?
Flags: blocking1.9.1.1-
Attachment #385091 - Flags: approval1.9.1.1? → approval1.9.1.2+
Comment on attachment 385091 [details] [diff] [review]
patch avoiding nspr
[Checkin: Comment 21 & 25]

a1912=beltzner
Flags: wanted1.9.1.x+
I've noticed there is no "nspr-config" in the xulrunner SDK (for both 1.9.1 and 1.9.2 - at least in the latest Linux nightly builds):
  http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/
  http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-mozilla-1.9.1/

It seems like there should be right?
For some reason this is only working on OSX.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
me == fail
Attachment #393545 - Flags: review?(ted.mielczarek)
Attachment #393545 - Flags: review?(ted.mielczarek) → review+
Landed, this should work now: http://hg.mozilla.org/mozilla-central/rev/00470cd4569c
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
(Thanks, Dave.
 I guess we'll want that change on 1.9.1 too, in a few days maybe.)
Dave: Does that patch apply to 1.9.1? Can you request approval if so?
Attachment #393665 - Flags: review?(bugzilla) → review+
Comment on attachment 393665 [details] [diff] [review]
fix comm-central packaging
[Checkin: Comment 33]

http://hg.mozilla.org/comm-central/rev/1a8ed893eaf2
Attachment #393665 - Attachment description: fix comm-central packaging → fix comm-central packaging [checked in]
Comment on attachment 393545 [details] [diff] [review]
fix packaging
[Checkin: Comment 29 & 36]

Verified that the mozilla-central nightlies are giving SDKs with nspr-config in it on all platforms, we should take this patch on the branch too
Attachment #393545 - Flags: approval1.9.1.3?
Comment on attachment 393545 [details] [diff] [review]
fix packaging
[Checkin: Comment 29 & 36]

Approved for 1.9.1.3. a=ss
Attachment #393545 - Flags: approval1.9.1.3? → approval1.9.1.3+
Attachment #393665 - Attachment description: fix comm-central packaging [checked in] → fix comm-central packaging [Checkin: Comment 33]
Attachment #393545 - Attachment description: fix packaging → fix packaging [Checkin: Comment 29 & 36]
Attachment #385091 - Attachment description: patch avoiding nspr → patch avoiding nspr [Checkin: Comment 21 & 25]
Attachment #377979 - Attachment is obsolete: true
Attachment #380194 - Attachment is obsolete: true
Target Milestone: mozilla1.9.2a1 → mozilla1.9.2b1
Version: unspecified → Trunk
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.