219233 - Move nsIChromeRegistry.idl into content (fix bad GRE dependencies)

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GRE Core, defect)

Description

[Benjamin Smedberg]

We currently have four implementations of nsIChromeRegistry...

rdf/chrome/* (seamonkey)
chrome/* (fbird/tbird)
embedding/lite/* (not finished?)
embedding/minimo/chromelite/*

Due to the fact that the chrome registry has been forked between seamonkey and
the XUL apps, I would like to 1) move all chrome registry impls out of the GRE
and 2) move nsIChromeRegistry.idl into content (because the interface is used
within the GRE by content and xpinstall), The actual packaging change will be
part of bug 20640, so this bug is just for the .idl move.

Comment 1

[Doug Turner (:dougt)]

I don't see a chrome in lxr.  is that something that doesn't
get indexed?  The last two "implementations" you listed will
eventually merge and potentially become the thing the the
GRE should include.... consider this....

The GRE should have some basic implementation of
something.... call it chrome if you want... basically the
GRE shouldn't require an embedder to build something that
allows gecko to fetch its own required files.  I do not
think that these core files require anything above the res
protocol.  That is exactly what the chromelite
implementation does.

Comment 2

[Benjamin Smedberg]

mozilla/chrome is not part of seamonkeyall (see
http://lxr.mozilla.org/mozilla/source/chrome/ it was forked by hyatt (with
brendan's permission) for firebird, because we are planning on incompatible
changes to the RDF schemas in firebird that we can't really make in seamonkey.
But I don't think is necessary to fork the interface (and it creates dependency
nightmares).

Which "core required files" are you thinking about? The GRE currently *doesn't*
contain chrome files, because there is no way to register them properly...
perhaps we should ship chromelite with the GRE and allow seamonkey/firebird to
override this impl separately?

Comment 3

[Doug Turner (:dougt)]

we should have something in the GRE that loads the set
of files, currently reference via chrome URLS, that a
any 'chromeless' embedding application will require.  
I believe that alec as attempting to do this with this
embedding/lite work.

Comment 4

[Benjamin Smedberg]

Attachment: move nsIChromeRegistry.idl into content

I agree WRT having some sort of chromeservice in embedding/GRE, but I want to
limit this bug very precisely to the duplicated nsIChromeRegistry.idl header
and the bad dependencies it creates... we can fix the packaging issues in bug
20640 or followup bugs.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Benjamin, I assume you will get the file moved in CVS to preserve cvs history,
right?

Comment 6

[Benjamin Smedberg]

It appears that normalize() is already called. The comments for nsILocalFile
specifically disallow initializing it with a relative path.

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryService.cpp#256

Comment 7

[Benjamin Smedberg]

Attachment: Too bad I can't request reviews from 4 people on one patch

oops, that last comment was for another bug

Comment 8

[Peter Van der Beken [:peterv]]

moa=jst,peterv for moving the interface into content.

Comment 9

[Jerry Talkington]

This looks like it's related to the recent checkins, let me know if I should
file a new bug on it:

c++ -o regchrome.o -c -DOSTYPE=\"Darwin6.8\" -DOSARCH=\"Darwin\" 
-I../../../dist/include/xpcom -I../../../dist/include/chrome
-I../../../dist/include/necko -I../../../dist/include/string
-I../../../dist/include/rdf -I../../../dist/include -I../../../dist/include
-I/Volumes/Vol2/jerry/src/firebird/Firebird-2003-12-22-06/dist/include/nspr    
-I/usr/X11R6/include   -mdynamic-no-pic  -I/sw/include -no-cpp-precomp 
-I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-long-long -I/sw/include -no-cpp-precomp -fpascal-strings -no-cpp-precomp
-fno-common -fshort-wchar -I/Developer/Headers/FlatCarbon
-F/System/Library/Frameworks -pipe  -DNDEBUG -DTRIMMED -O  -I/sw/include
-no-cpp-precomp  -I/usr/X11R6/include -DMOZILLA_CLIENT -include
../../../mozilla-config.h -Wp,-MD,.deps/regchrome.pp regchrome.cpp
regchrome.cpp:25:31: nsIChromeRegistry.h: No such file or directory
regchrome.cpp: In function `int main(int, char**)':
regchrome.cpp:97: error: `nsIChromeRegistry' undeclared (first use this 
   function)

Comment 10

[Benjamin Smedberg]

Fixed on trunk. This broke camino, but I don't know how to fix it. Also just
fixed he firebird build bustage in comment #9 which didn't appear on the
tinderboxen. 

Comment 11

[Jeff Walden [:Waldo]]

This looks like it *might* have broken the Firebird build.  See
http://forums.mozillazine.org/viewtopic.php?t=42069 for reports from several
people who have reported the build process broken.  Can someone look into this?
 The people in the MozillaZine post may also be checking this out from the other
end.

Comment 12

[Mickey Stein]

I had no time to figure this out but hacked it to work by doing a "find mozilla
-name 'nsIChromeRegistry.h' -print" and cp that file to
`~./mozilla/chrome/tools/chromereg' and it compiled fine. 

I think it's a make export problem due to the nsIChrome*.idl creating it's
respective *.h file, slapping it in the subdir "_*" and in dist/* but somehow
not exporting it correctly. (although it *reports* it as exporting it correctly
during the build). I know this is pure babbling, but have only got a  few
minutes at home right now to mess with it. 

I'd also done patch to Makefile.in ~./mozilla/chrome/tools/chromereg', but
everytime I do a fix this way, I realize that I've not yet got enough of the big
picture to be sure I'm not harming some other part of the tree. 

-------- 

Lastly for now, the other technique that worked was to cd  to
~./mozilla/chrome/tools/chromereg, and do a make from there after configure but
before the main toplvlsrc make. This implies that a simple reordering of the
make's might be of use. 

Comment 13

[Ludovic Hirlimann [:Usul]]

#10 the fix for camino is present in 229207

Comment 14

[Mike Pinkerton (not reading bugmail)]

so where did chrome.xpt move to? the "fix" that ludo suggested for camino was to
no longer include it, but i can't believe that's correct.