more thoughts on porting Chromium to FreeBSD

[René Ladan]

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 guess
that ideally there should be *_freebsd versions of these files and the
build system should know about them. If I understand correctly, this
should prevent the need for patches like:
+ ['OS=="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 files.

- 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.

- 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

- some knobs seem to be half-handled (e.g. use_system_libusb).
Concerning use_system_ knobs, would it be best to use as much system
libraries as possible? This would reduce the build time and the number
of patches. But on the other hand, testing more bundled libraries would
increase robustness.

- I made a port of Chromium 34.0.1847.45 to FreeBSD, see
https://github.com/gliaskos/freebsd-chromium (beta branch). This is
currently only build-tested and has some ugly hacks. I remember someone
else made a similar port, maybe we can combine efforts?

- At some point it would be really nice to have official FreeBSD build
bots, but this is probably only useful after a clean git checkout builds
on FreeBSD.

Regards,
René

[Torne (Richard Coles)]

On 10 March 2014 09:20, René Ladan <re...@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 guess
that ideally there should be *_freebsd versions of these files and the
build system should know about them. If I understand correctly, this
should prevent the need for patches like:
+        ['OS=="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 files.

"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), but in other places it means "POSIX system with a GNOME/KDE/similar desktop" and is mostly about dbus and xdg and related stuff. 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).

 

- 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 . It's probably not worth you putting much/any effort into this right now.

 

- 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.

 

- some knobs seem to be half-handled (e.g. use_system_libusb).
Concerning use_system_ knobs, would it be best to use as much system
libraries as possible? This would reduce the build time and the number
of patches. But on the other hand, testing more bundled libraries would
increase robustness.

- I made a port of Chromium 34.0.1847.45 to FreeBSD, see
https://github.com/gliaskos/freebsd-chromium (beta branch). This is
currently only build-tested and has some ugly hacks. I remember someone
else made a similar port, maybe we can combine efforts?

- At some point it would be really nice to have official FreeBSD build
bots, but this is probably only useful after a clean git checkout builds
on FreeBSD.

Regards,
René

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/531D83D1.2050005%40freebsd.org.

[René Ladan]

On 03/10/2014 11:16, Torne (Richard Coles) wrote:
> On 10 March 2014 09:20, René Ladan <re...@freebsd.org

> <mailto:re...@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 guess
> that ideally there should be *_freebsd versions of these files and the
> build system should know about them. If I understand correctly, this
> should prevent the need for patches like:
> + ['OS=="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 files.
>
>
> "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?

> 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, ...) ?

> 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.

>
>
> - 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é

[Torne (Richard Coles)]

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 :)

[Lei Zhang]

On Mon, Mar 10, 2014 at 9:59 AM, Torne (Richard Coles)
<to...@chromium.org> wrote:
> On 10 March 2014 16:13, René Ladan <re...@freebsd.org> wrote:
>> 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 :)

There is no hard rule. Use your best judgement on this. If the FreeBSD
implementation is completely different, or if trying to share code
with other POSIX implementations lead to #ifdef hell, then it might
make sense to break out the code into a _freebsd file.

In base/ there is a base/nix directory that's POSIX but not Mac.
However, the convention has no spread to other parts of the source
code.

Also, you may want to have this discussion on chromium-dev with a
wider audience, rather than chromium-packagers.

[René Ladan]

On 03/10/2014 18:22, Lei Zhang wrote:
> On Mon, Mar 10, 2014 at 9:59 AM, Torne (Richard Coles)
> <to...@chromium.org> wrote:
>> On 10 March 2014 16:13, René Ladan <re...@freebsd.org> wrote:
>>> 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 :)
> There is no hard rule. Use your best judgement on this. If the FreeBSD
> implementation is completely different, or if trying to share code
> with other POSIX implementations lead to #ifdef hell, then it might
> make sense to break out the code into a _freebsd file.

Yes, that would make the most sense I think.

> In base/ there is a base/nix directory that's POSIX but not Mac.
> However, the convention has no spread to other parts of the source
> code.

No, only files related to xdg there.

> Also, you may want to have this discussion on chromium-dev with a
> wider audience, rather than chromium-packagers.
>

Heh, I suggested that in the private mail but then ti was suggested to
send it to chromium-packagers instead.

René

[Lei Zhang]

On Mon, Mar 10, 2014 at 12:29 PM, René Ladan <re...@freebsd.org> wrote:
> On 03/10/2014 18:22, Lei Zhang wrote:
>> In base/ there is a base/nix directory that's POSIX but not Mac.
>> However, the convention has no spread to other parts of the source
>> code.
> No, only files related to xdg there.

That's probably one of the few things in base/ that's *nix-specific.
Most of the other base/foo_posix.cc files have a foo_win.cc equivalent
so they don't belong in base/nix.