From owner-freebsd-chromium@FreeBSD.ORG Mon Mar 10 16:59:29 2014 Return-Path: Delivered-To: chromium@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52073EE1 for ; Mon, 10 Mar 2014 16:59:29 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F347515D for ; Mon, 10 Mar 2014 16:59:28 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id e89so1336526qgf.5 for ; Mon, 10 Mar 2014 09:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VXc4DrnsaBxskafCvaT1tSbcERvAQLFvC7KisuKGvwY=; b=HFMsr37e5ZukEs1ZmRdNFgR4hPgbAd/qhmLPtrIAslJLnzbuIvfPwntIPFf2b6hpVW /fx2aEWl9AOQH5cZ7TXTrPX5DaTZ4vj5fmFk/54PkJ4EmqC4VxE+EmWHMw4Rimj0sycG zdYKdgREoD/gHhaxF3vmE8d/xP+B5B/XVxfdSywen+7buMiTxMESQZgrklRjFDAg8E4q 6HNugFl+J1aZfCX6BUiihOqehxXSATtYg5GuQp5I+BN5HbFYA+u/jocn9I8l33xTgz3/ rNvNqdzA5dyWKLf3n/7RqbttCSLzYEJfpRAb8H19vDV/JlKu59bGqvM/rqFEkWFAYHSM NRpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VXc4DrnsaBxskafCvaT1tSbcERvAQLFvC7KisuKGvwY=; b=KF6j4iRlk88g5nyurnGM9WvRLBnbgPCLYcb09bYPhZPwJrBWs3h4FDMm6JLXnYTnAL 9vJgRdUWi6rfKUkRHvSTUt4rieYCEhdkuvVj0BiAUKEksdr8aAjXCUBPLmuXwbSRep9o 7oPJowrzpr3TLidZ/ckIcwn3koKSr7WX0+Uf4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VXc4DrnsaBxskafCvaT1tSbcERvAQLFvC7KisuKGvwY=; b=Pw1U8oAJdDZLAK3dBWuPHI9oote59Ir86Gvrf/cJAk0XponfDXAcaCCYoOzOVnlTgK Q+eObcEAErlqFbvzgk00qqxSbOa8+K1fK1GAX8lynty85fRTDYGwjgWIhR4L5V46z2Us ueNvB1uY4FpGWfbANBsY46tVOefA6+5XHD69YhmSlIsBIRcJfUxYS6ejWWWlrYfGsuWS AGtxxZr0YeENISel+Swch5pcvoIb61XknbZy8bvSejYOEGpCCHjkhm301bn3tA/CbT3k SneibuO/12/4Q6iH67R7tUFFOdHYmEk5IYkOfT6VUqpjUUvZVme4881+yXR2q4UJflVX 4Idw== X-Gm-Message-State: ALoCoQnthh7rSKxl/PmvFcTomlilOnteU2KcD0yCYfHQ7QLDqXW7cDZDe537LTbfJ2awDTG/UinPtNmVcnCPjqWuPZ0Fma55cYnS9DoqIZZqT9HLxqX9X24c/M31xXc+4Y3AFr0dPkKw+F6vk87oMZoUdI/uOV7J7rJD87AAKu7sYOq48YsOrsPABTyjy7yVsyxHHOVG4Unn MIME-Version: 1.0 X-Received: by 10.224.136.195 with SMTP id s3mr3586094qat.95.1394470768056; Mon, 10 Mar 2014 09:59:28 -0700 (PDT) Sender: torne@google.com Received: by 10.229.162.200 with HTTP; Mon, 10 Mar 2014 09:59:27 -0700 (PDT) In-Reply-To: <531DE49E.8000207@freebsd.org> References: <531D83D1.2050005@freebsd.org> <531DE49E.8000207@freebsd.org> Date: Mon, 10 Mar 2014 16:59:27 +0000 X-Google-Sender-Auth: e_-NjGGhMzurpbJlPfz7dnsH-Z0 Message-ID: Subject: Re: [chromium-packagers] more thoughts on porting Chromium to FreeBSD From: "Torne (Richard Coles)" To: =?UTF-8?Q?Ren=C3=A9_Ladan?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: chromium-packagers@chromium.org, chromium@freebsd.org X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:59:29 -0000 On 10 March 2014 16:13, Ren=C3=A9 Ladan wrote: > On 03/10/2014 11:16, Torne (Richard Coles) wrote: > > On 10 March 2014 09:20, Ren=C3=A9 Ladan > > 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 >