Solaris support for Chromium

[jchoi42]

I first wrote this set of patches a while back, but the code has
changed a lot since, so I think it might be easier for anyone
interested in a port, as well as myself, if these could be applied
upstream. I'm not sure who to talk to about
this :)
These do not yet enable Chromium to build correctly on Solaris, but
are necessary before anything will begin to work. They are built
against svn 39027.

http://pha.jhu.edu/~jchoi42/chromiumpatches/new/patch_addsolaris
http://pha.jhu.edu/~jchoi42/chromiumpatches/new/patch_addsolaris2
http://pha.jhu.edu/~jchoi42/chromiumpatches/new/patch_addsolaris_specific

and this file
http://pha.jhu.edu/~jchoi42/chromiumpatches/prcpucfg_solaris.h

Sorry if this is not group relevant. I'm not sure who I'm supposed to
talk to about this. :)

Peace,
James Choi
jch...@pha.jhu.edu

[Peter Kasting]

We don't hand-post patches.  Just follow the instructions for getting a patch reviewed normally: get your depot_tools set up, make sure you're up to date, and gcl change/gcl upload.

PK 

[James Choi]

The website was unclear, so I've been emailing people, asking on
#chromium, asking people irl... am I supposed to talk to someone, or is
someone assigned to me? Do I upload somewhere first, or does a higher up
upload for me? The website made it sound like there was a review process,
and a sponsor who keeps track of how many patches someone has uploaded.
But it is unclear how to get a sponsor or a way to push upstream. It is
clear I can't get commit access without submitting patches, but how do I
submit patches without commit access or anyone to go through? Seriously,
it's really freaking confusing. Thanks.

Peace,
James Choi
jch...@pha.jhu.edu

> PK�
>
>

[Paweł Hajdan, Jr.]

So, you should download the source first, and then make a changeset
using gcl, like this:

gcl change solaris
gcl upload solaris

The second command will upload your change to
http://codereview.chromium.org. From there you should click
Publish+Mail comments, and choose some reviewers. In this case, you
can start with Evan Martin and me (we can add more reviewers if
needed).

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Peter Kasting]

On Tue, Feb 16, 2010 at 11:41 AM, James Choi <jch...@jhu.edu> wrote:

The website was unclear, so I've been emailing people, asking on #chromium, asking people irl... am I supposed to talk to someone, or is someone assigned to me? Do I upload somewhere first, or does a higher up upload for me? The website made it sound like there was a review process, and a sponsor who keeps track of how many patches someone has uploaded. But it is unclear how to get a sponsor or a way to push upstream. It is clear I can't get commit access without submitting patches, but how do I submit patches without commit access or anyone to go through? Seriously, it's really freaking confusing. Thanks.

I just rechecked http://dev.chromium.org/developers/contributing-code and it doesn't seem confusing to me, but maybe I'm too familiar with things.

To summarize that page:

* First get an opinion on whether what you're doing is desirable at all and if there are things to keep in mind.  In the case of Solaris support, the concerns I'd have would be maintenance (since the Chrome team isn't going to maintain Solaris, who is?) and effects on cross-platform code (is the cost we pay for cross-platform complexity worth the benefits?).  Note that for OSes like Windows 2000 we already decided that we're not OK with these tradeoffs, and rejected the idea of a Win2K port, so this is a serious issue.  If you haven't already, I'd create a thread on chromium-dev, in which you lay out the porting and maintenance plan and what the effects on existing code will be, as well as caveats for the port like "will it have a sandbox".

* File a bug at crbug.com about the work in question to track it.

* Create a changelist for your change(s).  Upload it.

* Find a reviewer.  In this case, phajdan.jr suggests himself and evan.  Mark those people as reviewers.  Then "publish + mail comments" to let them know they have a review.

* Once everything is acceptable, ask your reviewer to commit.

PK

[Evan Martin]

On Tue, Feb 16, 2010 at 8:48 PM, Peter Kasting <pkas...@google.com> wrote:
> * First get an opinion on whether what you're doing is desirable at all and
> if there are things to keep in mind.  In the case of Solaris support, the
> concerns I'd have would be maintenance (since the Chrome team isn't going to
> maintain Solaris, who is?) and effects on cross-platform code (is the cost
> we pay for cross-platform complexity worth the benefits?).  Note that for
> OSes like Windows 2000 we already decided that we're not OK with these
> tradeoffs, and rejected the idea of a Win2K port, so this is a serious
> issue.  If you haven't already, I'd create a thread on chromium-dev, in
> which you lay out the porting and maintenance plan and what the effects on
> existing code will be, as well as caveats for the port like "will it have a
> sandbox".

In the cases of relatively unpopular OSes like these, my attitude
(after talking with a few other people) has been:
- we are not going to officially support these platforms (which means
trunk will break for them, etc.)
- but in most cases support isn't too hard (pretty much every
non-Windows/Mac platform uses the same library stack as Linux, so it's
mostly a question of adjusting ifdefs)
- people are going to write the code anyway whether we let them
commit it or not
- so we might as well commit the bits that are known to be good;
frequently they are cleanups anyway

One good example of this is that we've traditionally guarded NSS code
with "#if defined(OS_LINUX)". But now that we're trying to use NSS on
Windows as well, we needed to adjust those to "#if defined(USE_NSS)"
(and add Windows to that define). It turns out the latter conversion
has already been done for many files by the FreeBSD patches anyway.

Concretely, this means for the FreeBSD port (and maybe OpenBSD) there
is already a working build:
http://chromium.jaggeri.com/
but it is 250kb of patch files; we are still slowly accepting/applying
pieces of it once they've been vetted for working with existing Chrome
quality requirements.

[Peter Kasting]

On Wed, Feb 17, 2010 at 4:44 AM, Evan Martin <ev...@google.com> wrote:

 - but in most cases support isn't too hard (pretty much every

non-Windows/Mac platform uses the same library stack as Linux, so it's
mostly a question of adjusting ifdefs)
 - people are going to write the code anyway whether we let them
commit it or not
 - so we might as well commit the bits that are known to be good;
frequently they are cleanups anyway

One good example of this is that we've traditionally guarded NSS code
with "#if defined(OS_LINUX)".  But now that we're trying to use NSS on
Windows as well, we needed to adjust those to "#if defined(USE_NSS)"
(and add Windows to that define).  It turns out the latter conversion
has already been done for many files by the FreeBSD patches anyway.

I'm fine with that.  It's patches that have significant negative effects on cross-platform code or maintenance burdens that bother me (as Win2K would).  If other OSes can get away with much more minimal changes I'm not opposed.

PK