Date: Mon, 17 Oct 2016 01:42:36 +0300 From: clutton <clutton@zoho.com> To: freebsd-chromium@freebsd.org Subject: Re: 54 version Message-ID: <1476657756.74649.27.camel@zoho.com> In-Reply-To: <1476561498.89083.13.camel@zoho.com> References: <1476416568.716.4.camel@zoho.com> <1476561498.89083.13.camel@zoho.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-BH6acWU68EEF5dCIPlZM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2016-10-15 at 22:58 +0300, clutton wrote: > On Fri, 2016-10-14 at 06:42 +0300, clutton wrote: Just fixed one major issue. Those user observers left, it would compile =C2=A0and work if two strings was commented but I would prefer to make appropriate patch, without cutting unknown. https://github.com/paranormal/freebsd-chromium/commit/771c6ac9fbd5be03b fb0ca5c6b848cc6896c0861 Could we please stop making new commits to the tree till this is merged? What is the point patching the old version if new is coming? When this would be ready, it would be very advisable to clean old patches. Some things are already in decent state in chromium codebase, no need to hack it around. Some approaches which I followed and think would be good: 1) GN: is_bsd, not is_freebsd, is_somebsd, just use one identifier. 2) C++ files: _bsd.cc, not _freebsd.cc and _openbsd.cc, the implementation can be divided inside like they divide Linux/Android/ChromeOS in one *.cc file. But we are far away from this... 3) C++ code: generally OS_BSD, in some cases OS_SOMEBSD when it is really needed. 4) Python: well... just ugly and I have no idea what to do with this now. A lot of different calls and approaches already exist in code. But fortunately it's not very important now and everyone could write python. P.S. Pathes are mostly clean (I know where they aren't and would clean them when major issues are resolved), the Makefile... just use it for now it wouldn't be hard to make it clean... P.P.S. Contact me if you have any questions. P.P.P.S. Advantages of new build: GN works really fast, generation ninja files takes much less time. Linking with lld is extremely fast and doesn't require a lot of RAM. Disadvantages: currently it uses almost all libraries from third_party. --=-BH6acWU68EEF5dCIPlZM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYBAJdAAoJEH2wP42yyP6QdNsQAIihVoOZkWgQ6gITz8f7mZLu eYUwn2OuBo3gdwbW72qfPCFiwrod3O3eoLTlMwwOeLgSb0RdjOeeZDC54gMBp7V4 n0ixsotxOcFC+6WMQKMcACQmZ9s8QhsjseAAZNoYooczE5xMCMyt8hHuLfg/p9ys beQuqutn0TKCJZK3z61KiMqhcGgGayZPXHvM1JtPZsZCr1c/ylEBI7LZHtInbcy9 dFSy+/RcMhJb8kvTiSOJsoyhIYXYhrbxxjEwv9Kp9ZkARyLSqlCC2EiCzvKwmZQ6 Z8t5D4S2R27ryaKrCWHP+u/R12arXcVLwaG4JLqjOuoRXgpxKulUYB5Q9GIAbU7X 3HBRYHF9GutlvmbKRJ2+IYnreNlspG30kDoJkcaEpf2LIf3wpPCSEalKpB9IC7G3 lMs8zgfKxfRWdS/wBtLdVifUK4UNRKJAEn91znDrikOhyZXS16NoputJEicNx0xN eOfUG+JeLEOpUDGhiSSW2W7uQLv4ACRgJ8rvIQE0J11NEB7BwrkXgryGlKYxu9dx YeIABN1vq9UcPMUdW+hPMj4WF2kNz7fEAk9DDquUNJMEeDE3G8yCFfQlnxATnszd rL9iHKD2bjjMgdfCk0EVsA7bdgOi4gQXq5eUVsHNFdTxcExhNNRXXWJ1MizvG7AQ a77d/7qDIVs6kXhNmDFq =FhKg -----END PGP SIGNATURE----- --=-BH6acWU68EEF5dCIPlZM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1476657756.74649.27.camel>