163317 - remove libreg from xpcom (and most embedders)

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Brian Ryner (not reading)]

If I understood our conversation correctly about bug 149208, libreg can now be
removed from the build since we don't rely on it for anything.

Comment 1

[Doug Turner (:dougt)]

close, but not there completely yet.  profiles still use it.

Comment 2

[Stephen Walker]

dougt: does bug 174522 address the use of libreg in profiles?

Comment 3

[Doug Turner (:dougt)]

sure sounds like it.  conrad, when are you planning to have profiles stop using
the registry format?  I really want to see libreg move out of xpcom and into
xpinstall.

Comment 4

[Conrad Carlen (not reading bugmail)]

In 1.3. WRT profile mgr, it's next in line after GRE profile sharing.   Problem
is, because of the need to migrate existing profile registries, we'll always
need libreg from profile mgr. Moving it out of xpcom is the right thing to do,
though. Since it's needed by xpinstall and profile mgr, it may need to be a
standalone dll rather than being linked into xpcom.

Comment 5

[Doug Turner (:dougt)]

Attachment: moves nsRegistry code to modules/libreg/xpcom

this is an ugly patch, but most of it is a file move.

I moved the following files:
from xpcom/components/

nsIRegistry.idl
nsIRegistryUtils.h
nsRegistry.cpp
nsRegistry.h

to modules/libreg/xpcom

The only modification to these files were at the botton of nsRegistry.cpp where
I used our generic factories to create a module.

Comment 6

[Doug Turner (:dougt)]

i am asking leaf to move these files so that this patch looks more sane.

Comment 7

[Daniel (Leaf) Nunes]

copy done.

Comment 8

[Doug Turner (:dougt)]

Attachment: cleaner patch

Comment 9

[Doug Turner (:dougt)]

I am not longer calling NR_StartupRegistry/NR_ShutdownRegistry.  Not sure if
this is a problem.

Comment 10

[Conrad Carlen (not reading bugmail)]

Basically looks OK, but:

             // can't use NS_GetSpecialDirectory here.  Called before service
manager is initialized.
             EnsureDefaultRegistryDirectory();
-            nsCOMPtr<nsIProperties> directoryService;
-            rv = nsDirectoryService::Create(nsnull,

This comment isn't (or better not be) true anymore. Get rid of it.
  

I take it you made a modules/libreg/xpcom/Makefile.in but it's not in the patch
because you didn't use -N? As far as that goes, can you make the Mac projects to
build the stuff in its new location?

Comment 11

[Doug Turner (:dougt)]

I am going to need a mac buddy to help me create the project file.  conrad, can
you do this for me?

new patch coming up with your suggestion and the Makefile changes.

Comment 12

[Doug Turner (:dougt)]

Attachment: with makefile's

does not include the patch to remove xpcom/components/nsIRegistry.idl
xpcom/components/nsIRegistryUtils.h xpcom/components/nsRegistry.cpp
xpcom/components/nsRegistry.h xpcom/tools/registry/regExport.cpp

Comment 13

[Conrad Carlen (not reading bugmail)]

> conrad, can you do this for me?

Yeah - I can do it and put the additional Mac stuff on this bug.

Comment 14

[Doug Turner (:dougt)]

Attachment: another update.

Comment 15

[Conrad Carlen (not reading bugmail)]

Attachment: patch for Mac CFM build

Two new projects:
(1) to build the new mozreg component
(2) to build the IDL for nsIRegistry.idl
And all the various MANIFESTs, build script changes, etc.

Comment 16

[Doug Turner (:dougt)]

Attachment: patch 1.314

This includes Conrad's CFM patch.

Comment 17

[Conrad Carlen (not reading bugmail)]

Comment on attachment 105341 [details] [diff] [review]
patch 1.314

Looks good. r=ccarlen if this doesn't increase startup time any. I'm a little
concerned that	NS_StartupRegistry/NS_ShutdownRegistry is getting called more
often now (I can see one additional time in profile mgr) This may not be
significant, but check.

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 105341 [details] [diff] [review]
patch 1.314

You've got a little bit of your "signed XPI" patches mixed in here... I'll
ignore that for now.

>Index: embedding/config/basebrowser-win

mozreg wasn't in the Mac or Unix lists? Hm, why not?

>Index: extensions/python/xpcom/src/loader/Makefile.in
>===================================================================
>-REQUIRES	= xpcom string $(NULL)
>+REQUIRES	= xpcom string mozreg $(NULL)

Does this imply that the python loader has not been switched over to use the
new component registry?

>Index: xpinstall/packager/packages-os2
>===================================================================

Don't you need to add the mozreg component to this one, too?

>Index: xpinstall/packager/packages-static-unix
>===================================================================
>+bin/components/libmozreg.so
>+bin/components/mozreg.xpt

On a static build unless you do something special the .so should be
part of the main statically linked blob. The xpt is still needed though.

>Index: xpinstall/packager/packages-static-win
>===================================================================
>+bin\components\mozreg.dll
>+bin\components\mozreg.xpt

DItto. I could be wrong though. Check with Cathleen or cls.

>Index: xpinstall/packager/packages-unix
>===================================================================
>+bin/components/libmozreg.so
>+bin/components/mozreg.xpt

I don't believe the stub installer will need this because you've
linked duplicate code into the xpinstall library. Maybe these should
go in the browser section instead. Same in all these package lists

>Index: xpinstall/src/nsXPInstallManager.cpp
>===================================================================
>+    NR_StartupRegistry();
>+    NR_ShutdownRegistry();

This should go in the main nsSoftwareUpdate service, which can be
used apart from the nsXPInstallManager.

Oh wait, it already does this. Just drop these additions, should work fine.

I'd like to see another patch with the cleanup (and no signed XPI mix-ins)
Thanks, looks good

Comment 19

[Doug Turner (:dougt)]

> mozreg wasn't in the Mac or Unix lists? Hm, why not?

Duh!  I am going to include ccarlen's changes...

>Does this imply that the python loader has not been switched over to use the
new component registry?

Nope.  They use the nsIRegistry hence the requrires tag.

>Don't you need to add the mozreg component to this one, too?

Fixed.


>On a static build unless you do something special the .so should be
part of the main statically linked blob. The xpt is still needed though.

Fixed.

>This should go in the main nsSoftwareUpdate service, which can be
used apart from the nsXPInstallManager.

Fixed


New patch coming up.

Comment 20

[Doug Turner (:dougt)]

Attachment: patch e

Comment 21

[Doug Turner (:dougt)]

Attachment: with alec's suggestion - no new dll.

we build mozreg as a static lib and link it into profile. (mac project files
need some love)

Comment 22

[neeti]

me

Comment 23

[neeti]

doug

Comment 24

[Doug Turner (:dougt)]

Attachment: updated patch

cconrad/darin can I get reviews please?

Comment 25

[Doug Turner (:dougt)]

fixed.  only profile manager and xpcom require libreg.