remove libreg from xpcom (and most embedders)

RESOLVED FIXED in mozilla1.4alpha

Status

()

Core
XPCOM
--
major
RESOLVED FIXED
16 years ago
9 years ago

People

(Reporter: Brian Ryner (not reading), Assigned: dougt)

Tracking

Trunk
mozilla1.4alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 8 obsolete attachments)

(Reporter)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
close, but not there completely yet.  profiles still use it.
Target Milestone: --- → Future
(Assignee)

Updated

15 years ago
Target Milestone: Future → mozilla1.3alpha

Comment 2

15 years ago
dougt: does bug 174522 address the use of libreg in profiles?
(Assignee)

Comment 3

15 years ago
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.
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.
(Assignee)

Comment 5

15 years ago
Created attachment 103283 [details] [diff] [review]
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.
(Assignee)

Comment 6

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

Comment 7

15 years ago
copy done.
(Assignee)

Comment 8

15 years ago
Created attachment 103385 [details] [diff] [review]
cleaner patch
Attachment #103283 - Attachment is obsolete: true
(Assignee)

Comment 9

15 years ago
I am not longer calling NR_StartupRegistry/NR_ShutdownRegistry.  Not sure if
this is a problem.
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?
(Assignee)

Comment 11

15 years ago
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.
(Assignee)

Comment 12

15 years ago
Created attachment 103394 [details] [diff] [review]
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
Attachment #103385 - Attachment is obsolete: true
> conrad, can you do this for me?

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

Comment 14

15 years ago
Created attachment 105116 [details] [diff] [review]
another update.
Attachment #103394 - Attachment is obsolete: true
Created attachment 105273 [details] [diff] [review]
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.
(Assignee)

Comment 16

15 years ago
Created attachment 105341 [details] [diff] [review]
patch 1.314

This includes Conrad's CFM patch.
Attachment #105116 - Attachment is obsolete: true
Attachment #105273 - Attachment is obsolete: true
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.
Attachment #105341 - Flags: review+
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
Attachment #105341 - Flags: superreview-
(Assignee)

Comment 19

15 years ago
> 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.
(Assignee)

Comment 20

15 years ago
Created attachment 106054 [details] [diff] [review]
patch e
Attachment #105341 - Attachment is obsolete: true
(Assignee)

Comment 21

15 years ago
Created attachment 106132 [details] [diff] [review]
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)
Attachment #106054 - Attachment is obsolete: true

Comment 22

15 years ago
me
Assignee: dougt → neeti

Comment 23

15 years ago
doug
Assignee: neeti → dougt
(Assignee)

Updated

15 years ago
Summary: remove libreg → remove libreg from xpcom (and most embedders)
(Assignee)

Comment 24

15 years ago
Created attachment 113175 [details]
updated patch

cconrad/darin can I get reviews please?
Attachment #106132 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Severity: normal → major
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
(Assignee)

Comment 25

15 years ago
fixed.  only profile manager and xpcom require libreg.  
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

9 years ago
Component: XPCOM Registry → XPCOM
QA Contact: doug.turner → xpcom
You need to log in before you can comment on or make changes to this bug.