On Thu, Jan 14, 2010 at 1:33 PM, Brian G. Merrell <bgmerr...@gmail.com> wrote: > Okay, I started looking into this. After a bit of work, I'm to the > point where I need to process the master_preferences json file. > That is, I am currently writing a ProcessMasterPreferences function > in first_run_gtk.cc. It looks like for Windows much of the work for > processing the file is done using install_util, which doesn't appear > to even be included in the build for Linux. So, I have a couple of > questions... > > What would be the preferred approach to processing the > master_preferences file in Linux? At a glance, it looks like > chrome/installer/util/master_preferences.cc might have everything > needed if it was built it for Linux, but should the parsing be done > somewhere more general and/or more portable? Documentation says > that chrome/installer has "source files and projects for making the > installer (MSI package)."
I don't remember this code too well, but it sounds like perhaps processing the master preferences belongs in a shared location. Or maybe it's already in the appropriate shared location and we can build a minimal Linux installer_util library that just includes the master preferences code you want. See installer_util.gypi and chrome.gyp's mention of intaller.gyp to see where you'd need to tweak this. I'd take a look at the code that *uses* the master preferences to judge what makes sense to do here. > My other question is about the location of the master_preferences > file. In Windows, the file is required to be located in the same > directory as the chrome EXE (DIR_EXE). For Linux, I'm not sure that > this would fit. Any thoughts? It doesn't seem too terrible to me. We currently don't put any files outside of /opt for the Google Chrome packages; I guess at some point it would be nice to put data /usr/share, etc. at which point maybe it'd make sense to extend PathService to provide additional directories. But that's probably outside the scope of the change you're trying to make. > I will attach what I've come up with so far, in case someone is > interested. There are probably things I've done already that are > completely wrong :) It is tons easier to look at patches if you upload them to our review site. It's pretty easy to do; see http://www.chromium.org/developers/contributing-code if you're using svn. You can set me as the reviewer and write in your message "just looking for feedback, not ready to commit yet" and I can look there. One thing I'd consider is how this might work on the Mac. I don't think you should worry about implementing it, but I find considering how code *could* be shared helps me think of the appropriate abstraction layers and locations to implement these pieces.
-- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev