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
