Fork bookmarks for Phoenix work

VERIFIED FIXED

Status

VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: hyatt, Assigned: hyatt)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

16 years ago
The rule is "don't add Phoenix ifdefs", which means I need to fork bookmarks 
for the Web Panels work in Phoenix.  Here is the patch that shifts bookmarks 
stuff into the already-existing #ifndef MOZ_PHOENIX blocks.
(Assignee)

Comment 1

16 years ago
Created attachment 120335 [details] [diff] [review]
xpfe/components builds changes

Comment 2

16 years ago
Comment on attachment 120335 [details] [diff] [review]
xpfe/components builds changes

Hyatt continues to amaze me.  Between his work at apple and his grossly illegal
underage porn selling business, I don't know where he finds the time.
Attachment #120335 - Flags: superreview+
Attachment #120335 - Flags: review+
I don't think we have a hard-and-fast rule; just a dislike for adding ifdefs
instead of solving the real problem.... (that's what the situation was last time
I saw this come up).

Maybe we can make bookmarks flexible enough to not need forking by every UI
implementor?
Comment on attachment 120335 [details] [diff] [review]
xpfe/components builds changes

>Index: build/Makefile.in
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/build/Makefile.in,v
>retrieving revision 1.49
>diff -u -r1.49 Makefile.in
>--- build/Makefile.in	8 Apr 2003 08:51:49 -0000	1.49
>+++ build/Makefile.in	12 Apr 2003 21:38:07 -0000
>@@ -86,6 +85,7 @@
> 
> ifndef MOZ_PHOENIX
> SHARED_LIBRARY_LIBS += \
>+  $(DIST)/lib/$(LIB_PREFIX)bookmarks_s.$(LIB_SUFFIX) \
> 	$(DIST)/lib/$(LIB_PREFIX)downloadmanager_s.$(LIB_SUFFIX) \
> 	$(DIST)/lib/$(LIB_PREFIX)autocomplete_s.$(LIB_SUFFIX) \

The rest of these lines are using hard tabs; please do the same.

r/sr=bryner other than that.
Actually, there's one other change you might want to make.  As you have it 
now, we'll compile stuff in xpfe/components/bookmarks, and just not link it 
into the dll.  If you forked nsIBookmarksService.idl too, you could skip 
building in xpfe/components/bookmarks at all (there's a section in 
xpfe/components/Makefile.in for directories that are only built for 
seamonkey).  You'll hit ordering problems though... for reasons I'm sure I'd 
rather not know about, nsHTMLDocument needs nsIBookmarksService.h, and since 
browser is in a later 'tier' than content in the toplevel Makefile.in, that 
header won't be exported at the time content needs it.
Why does Gecko, a more primitive thing, depend on an interface header exported
by xpfe?  I've beaten others up about such mistakes in the past.  Who do I beat
up now?  Let's consult lxr, shall we?

revision 3.239
date: 2000/06/01 01:13:45;  author: jbetak%netscape.com;  state: Exp;  lines: +53 -5
18022, bookmark doc charset caching
r=rjc, ftang, a=ftang

Before the era of super-review, wheeee!

I'll pre-sr anyone on the cc: list who gets rid of this bogus dependency.

/be
(Assignee)

Comment 7

16 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 8

16 years ago
I followed the instructions on http://phoenix.ragweed.net/build and downloaded
the latest mozilla tarball. I did a 'gmake -f client.mk fast-update' and sync'd
the tree before building. On my laptop, running Red Hat 8.0, I get this error
upon entering the mozilla/browser/components/build dir:

gmake[5]: Entering directory
`/home/duncan/src/phoenix-source/mozilla/browser/components/build'
...

c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-pedantic -Wno-long-long -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2
-march=i686 -fPIC -shared -Wl,-h -Wl,libbrowsercomps.so -o libbrowsercomps.so 
nsModule.o       -Wl,--whole-archive ../../../dist/lib/libdownload_s.a
../../../dist/lib/libbookmarks_s.a  -Wl,--no-whole-archive 
../../../dist/lib/libunicharutil_s.a -L../../../dist/bin -lxpcom 
-L../../../dist/bin -L/home/duncan/src/phoenix-source/mozilla/dist/lib -lplds4
-lplc4 -lnspr4 -lpthread -ldl  -L../../../dist/lib -lxpcom_compat
-L../../../dist/bin -lmozjs  -Wl,--version-script
-Wl,../../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic
-ldl -lm  -lole32 -lshell32   
/usr/bin/ld: cannot find -lole32
collect2: ld returned 1 exit status

Is this to be expected?

Comment 9

16 years ago
Brendan, it looks as if the document gets the charset from the bookmark (if
there's a bookmark for that page with a forced charset). I expect it would be
reasonable to make opening a bookmark force the charset instead.
Note that those are not exactly equivalent... (though I do prefer Neil's
solution... ;))
Comment on attachment 120335 [details] [diff] [review]
xpfe/components builds changes

This doesn't even compile for me, since you didn't ifdef the #include of
nsBookmarksService.h at the top of nsModule.cpp (but you did change the
LOCAL_INCLUDES conditionally for phoenix so that it can't be found).

I also get the error in comment 8.
Comment on attachment 120447 [details] [diff] [review]
some attempts to fix bustage

er, yeah. r/sr=me.
Attachment #120447 - Flags: superreview+
Attachment #120447 - Flags: review+
checked in the patch.
Created attachment 120539 [details] [diff] [review]
additional bustage fix 

Yeah, I didn't clobber.  This should help.  (Although I see bryner's checked in
a bit of other stuff already.)

Comment 16

16 years ago
Verified per last comments
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.