Closed Bug 75924 Opened 24 years ago Closed 16 years ago

make --with-extensions=all do what it says

Categories

(Firefox Build System :: General, defect, P5)

All
Linux
defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: dbaron, Assigned: dbaron)

Details

Attachments

(6 files)

I'd like to make --with-extensions=all more accurate, so that people who are trying not to break extensions will actually build all working extensions when the try to do so. This would mean that the tinderboxes (on Ports) that build --with-extensions=all would be building these extensions. As a first pass, I'd like to add the extensions that clearly seem ready to be built -- those that are in allmakefiles.sh -- part of --with-extensions=all. That means adding inspector, access-builtin, and transformiix to --with-extensions=all. hewitt, aaronl, and peterv: Is this OK with you? I'll attach a patch once I add the REQUIRES lines...
It would be nice to fix the transformiix build system to use archives rather than do everything (again) in extensions/transformiix/build/Makefile.in first though...
Adding Axel Hecht, he knows much more about the Transformiix unix build system than I do. David, could you expand a little on your last comment, I don't understand what you mean. Also note that Transformiix is very close to being turned on in the default build.
Adding inspector is fine with me. It should build on win32, mac, and linux... who knows what will happen on other platforms.
transformiix is blocked by the old makefiles. See 74879. Concerning David (recap of irc discussion): I don't like the idea of static libs more or less than listing the object files twice. "Due to historical reasons" bla applies. We have a few dirs with just one .cpp, and my fingers curl up to my knees on the idea of static libs for those. IMHO, it's not worth the effort converting. Axel
r=cls on attach 30774. I assume that changes for vixen, p3p, etc are in the works?
I'd would like the REQUIRES lines in transformiix to be ifdef MOZ_XSL. Currently, only the mozmodule depends on other stuff in mozilla, and we might at one time have a dependency on string only for standalone. Axel
aaronl said (on IRC) that this is fine with him. So I just need to #ifdef those REQUIRES lines...
r=cls
extensions=all would build transformiix standalone this way, but to build the moz module, you need to set MOZ_XSL. This should be synched/merged with 72141. Axel
Status: NEW → ASSIGNED
I tested that it works without --enable-xsl as well. I'd like to see this go in before bug 72141, so that we don't have to check it in urgently to fix the bustage on senna. (There are also some other issues in bug 72141 that seem to need to be addressed.)
sr=hewitt
David, if you've verified that it builds the transformiix module (not the standalone), r=peterv. I'm surprised that that works.
No, it (without --enable-xsl) builds the standalone. But I'd rather have this in first and then fix bug 72141 (which would involve making it so that it really builds the transformiix module).
I just checked in the bustage fixes (including the ifdef-ed REQUIRES lines for transformiix) and I added access-builtin and inspector to --with-extensions=all, but I didn't add transformiix yet, since it would currently build the standalone (cls agreed that it should wait). It should be added as part of bug 72141.
r=cls on the latest attach
LIB_SUFFIX is preferred over hardcoding .a
Fixed the error mkaply pointed out. (For the record, the patch above fixed the fact that we were creating "libinspector_s" and ".a" where we should have been creating "libinspector_s.a", and the cause of the problem was a space at the end of the LIBRARY_NAME line.) I also had to make inspector link against gkgfx and libgkconshared_s to fix AIX bustage. The latter dependency really has to go. The errors that led me to do that were: ld: 0711-317 ERROR: Undefined symbol: .NS_HexToRGB ld: 0711-317 ERROR: Undefined symbol: .nsCSSProps::AddRefTable() ld: 0711-317 ERROR: Undefined symbol: .nsCSSProps::ReleaseTable() ld: 0711-317 ERROR: Undefined symbol: .nsCSSProps::GetStringValue(nsCSSProperty) ld: 0711-317 ERROR: Undefined symbol: .nsCSSProps::LookupProperty(const nsAString&) (I wonder why it was linking against rdfutil_s to begin with... that would be good to remove as well.) I also fixed some true->PR_TRUE and false->PR_FALSE bustage in inspector and one file in access-builtin that had Windows line endings.
I filed bug 79091 about inspector's link-time dependencies.
Finishing this isn't at the top of my radar right now. If someone else wants to, go ahead. The first bit was a good bit more work than I intended...
Priority: -- → P4
Target Milestone: --- → Future
I'll have a patch for the next step shortly. This patch adds: ctl cview p3p universalchardet vixen pics seems to require numerous files that aren't in the tree. python seems complicated. This patch adds new Makefile.in files for universalchardet and makes extensive changes to p3p to get it building again (since it clearly hasn't been built for quite a while).
Target Milestone: Future → mozilla0.9.4
r=cls on the makefile changes
harishd said by email that the p3p changes were fine with him yokoyama said adding the universalchardet makefiles was fine (and noted bug 92341, which says it should be on by default) I still haven't heard back from katakai (for ctl), rginda (for cview), or ben (for vixen).
I'm actually thinking I probably shouldn't add p3p since it adds significant leaks to startup and that will make the leak stats more confusing.
There's a separate bug for ctl, bug 95258.
sr=tor
Target Milestone: mozilla0.9.4 → mozilla0.9.5
*** Bug 91305 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → Future
Priority: P4 → P5
*** Bug 221233 has been marked as a duplicate of this bug. ***
I'm not sure that Bug 221233 is actually a duplicate of this one, since cview is actually included in --with-extensions=all in configure, but it just doesn't get compiled. (Or is that what this bug is about?)
Product: Browser → Seamonkey
David, Are you still working on this ?
No.
Product: Mozilla Application Suite → Core
And as bug 450015 notes, neither was anyone else. At all. Ever.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
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: