Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Mar 2014 16:59:27 +0000
From:      "Torne (Richard Coles)" <torne@chromium.org>
To:        =?UTF-8?Q?Ren=C3=A9_Ladan?= <rene@freebsd.org>
Cc:        chromium-packagers@chromium.org, chromium@freebsd.org
Subject:   Re: [chromium-packagers] more thoughts on porting Chromium to FreeBSD
Message-ID:  <CAEV-rjf7t6CY_VWczfGhp25EUQyTjSUd%2BA4pphfE7YbHH2n=mw@mail.gmail.com>
In-Reply-To: <531DE49E.8000207@freebsd.org>
References:  <531D83D1.2050005@freebsd.org> <CAEV-rjdoJg7%2BUvC8Mtdy4xGHz5BdVAEq%2BNUrponhXNQrboeV=Q@mail.gmail.com> <531DE49E.8000207@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10 March 2014 16:13, Ren=C3=A9 Ladan <rene@freebsd.org> wrote:

> On 03/10/2014 11:16, Torne (Richard Coles) wrote:
> > On 10 March 2014 09:20, Ren=C3=A9 Ladan <rene@freebsd.org
> > <mailto:rene@freebsd.org>> wrote:
> >
> >     Hi,
> >
> >     [this is an updated rewrite of an earlier private mail]
> >
> >     some more thoughts and ideas I gathered while porting Chromium to
> >     FreeBSD:
> >     - FreeBSD seems to piggy-back on Linux too much because ninja will
> >     build
> >     *_linux files on FreeBSD which might or might not be useful. I gues=
s
> >     that ideally there should be *_freebsd versions of these files and
> the
> >     build system should know about them. If I understand correctly, thi=
s
> >     should prevent the need for patches like:
> >     +        ['OS=3D=3D"freebsd"', {
> >     +         'sources/': [
> >     +           ['exclude',
> >     '^browser/storage_monitor/udev_util_linux.cc'],
> >     ....
> >     where linux files are explicitly excluded afterwards. Which leads
> >     to the
> >     question what file(s) decide that FreeBSD should build *_linux file=
s.
> >
> >
> > "linux" in the chromium tree means a lot of different things depending
> > on context; in some places it means "thing that depends on
> > Linux-specific C library/syscall functionality" (e.g. most uses in
> > src/base),
> So in this case _freebsd versions should be made?
>

Probably in some cases, yes (and it may just have to be stubs/etc if the
functionality in question just plain doesn't exist). In other cases it
might be that these are not *that* linux specific still and may work anyway
:)


> > but in other places it means "POSIX system with a GNOME/KDE/similar
> > desktop" and is mostly about dbus and xdg and related stuff.
> and in this case probably not. Should the _linux files be renamed to
> something more generic (_posix, _unix_desktop, ...) ?
>

There's already a _posix extension, and that's used for mac and android as
well as linux, since those are all POSIX systems. Things named just _posix
can't assume the presence of gnome/kde/freedesktop.org since they don't
exist on mac/android. It's possible there are enough things that fall into
this category that a more general name and gyp filter would be useful, but
I think you'd have to check first whether there are really that many :)


> > I'm not sure whether you'll do better by including linux sources by
> > default and excluding the ones that aren't appropriate for *BSD, or
> > excluding them and then re-including the ones that are relevant (you
> > don't want to have to write a BSD-specific version of anything that
> > isn't absolutely necessary).
> Hm, there does not seem to be a hard rule here. Somehow having dedicated
> _freebsd files looks cleaner but that does impose more work.
>

It might look cleaner but if there are cases where the code in _freebsd
would be basically the same, or literally identical, then this makes
maintaining the codebase much harder. Duplication is bad :)


> >
> >
> >     - GN probably needs to be ported to FreeBSD to be able to continue
> >     bootstrapping the build. I sent tickets for this after making the
> >     bootstrap binary run on both FreeBSD 8.4-i386 (oldest supported
> >     version
> >     of we omit FreeBSD 8.3 which will expire after April) and FreeBSD
> >     10.0-amd64 (latest release). The main ticket is 180743014 which
> >     depends
> >     on tickets 178193018 and 185713005.
> >
> >
> > Just to let you know, the gn project is being put on hold and the
> > invocations of it are going to be removed from chromium's build
> > process: see
> >
> https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/gn=
/chromium-dev/LQKLbTU-PuU/8akR_c84JZ8J
> > <
> https://groups.google.com/a/chromium.org/forum/#%21searchin/chromium-dev/=
gn/chromium-dev/LQKLbTU-PuU/8akR_c84JZ8J
> >
> > . It's probably not worth you putting much/any effort into this right
> now.
> Ah, I sent in those tickets just before this was announced. But only the
> first one is specific to GN, the other two are more generic.
>
> >
> >
> >     - Possibly related to GN is this error that I get when running
> >     "ninja -C
> >     out/Release" in my tip-of-tree git checkout:
> >     ninja: Entering directory `out/Release'
> >     ninja: error:
> >
> '../../chrome/renderer/resources/extensions/bluetooth_custom_bindings.js'=
,
> >     needed by 'gen/chrome/grit/renderer_resources.h', missing and no
> known
> >     rule to make it
> >
> >
> > This isn't related to gn; grit is the normal resource generation tool.
> > If this doesn't work then the hooks haven't run correctly, or the
> > revision you have is broken.
> Woops, this was because my script was running gyp_chromium with a
> vanilla GN (which does not know about FreeBSD) and therefore it never
> runs GYP before invoking ninja. It runs fine again apart from expected
> breakage.
>
> Regards,
> Ren=C3=A9
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEV-rjf7t6CY_VWczfGhp25EUQyTjSUd%2BA4pphfE7YbHH2n=mw>