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.
close, but not there completely yet. profiles still use it.
Target Milestone: --- → Future
dougt: does bug 174522 address the use of libreg in profiles?
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.
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.
i am asking leaf to move these files so that this patch looks more sane.
Created attachment 103385 [details] [diff] [review] cleaner patch
Attachment #103283 - Attachment is obsolete: true
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?
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.
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.
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.
Created attachment 105341 [details] [diff] [review] patch 1.314 This includes Conrad's CFM patch.
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-
> 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.
Created attachment 106054 [details] [diff] [review] patch e
Attachment #105341 - Attachment is obsolete: true
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
Assignee: dougt → neeti
Assignee: neeti → dougt
Summary: remove libreg → remove libreg from xpcom (and most embedders)
Created attachment 113175 [details] updated patch cconrad/darin can I get reviews please?
Attachment #106132 - Attachment is obsolete: true
Severity: normal → major
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
fixed. only profile manager and xpcom require libreg.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.