• [gentoo-dev] [PATCH] media-libs/freetype: fix GCC usage during configur

    From Adrian Ratiu@21:1/5 to All on Fri Jan 7 14:10:01 2022
    If $CC_BUILD is not set, configure defaults to GCC for some
    of its tests causing clang builds to use a mixture of the
    two compilers instead of using just clang consistently.

    Here is an example before and after setting CC_BUILD (this
    is actually from ChromiumOS where this was first detected).

    before:

    checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
    checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc checking for suffix of native executables...

    after:

    checking for x86_64-pc-linux-gnu-gcc... x86_64-cros-linux-gnu-clang
    checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-cros-linux-gnu-clang checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-cros-linux-gnu-clang checking for suffix of native executables...

    Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
    ---
    media-libs/freetype/freetype-2.11.0-r1.ebuild | 2 ++
    media-libs/freetype/freetype-2.11.0-r2.ebuild | 2 ++
    media-libs/freetype/freetype-2.11.1.ebuild | 2 ++
    media-libs/freetype/freetype-9999.ebuild | 2 ++
    4 files changed, 8 insertions(+)

    diff --git a/media-libs/freetype/freetype-2.11.0-r1.ebuild b/media-libs/freetype/freetype-2.11.0-r1.ebuild
    index b4e9e81a703..c9d88a7e108 100644
    --- a/media-libs/freetype/freetype-2.11.0-r1.ebuild
    +++ b/media-libs/freetype/freetype-2.11.0-r1.ebuild
    @@ -203,6 +203,8 @@ multilib_src_configure() {
    *) myeconfargs+=( ac_cv_prog_RC= ac_cv_prog_ac_ct_RC= ) ;;
    esac

    + export CC_BUILD="$(tc-getBUILD_CC)"
    +
    ECONF_SOURCE="${S}" econf "${myeconfargs[@]}"
    }

    diff --git a/media-libs/freetype/freetype-2.11.0-r2.ebuild b/media-libs/freetype/freetype-2.11.0-r2.ebuild
    index 658322e92af..27f4cfde1ab 100644
    --- a/media-libs/freetype/freetype-2.11.0-r2.ebuild
    +++ b/media-libs/freetype/freetype-2.11.0-r2.ebuild
    @@ -204,6 +204,8 @@ multilib_src_confi
  • From Sam James@21:1/5 to All on Sat Jan 8 06:20:01 2022
    --Apple-Mail=_24EF3F33-1CDF-4AEF-9F39-09938F0A96E7
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain;
    charset=us-ascii



    On 7 Jan 2022, at 13:08, Adrian Ratiu <adrian.ratiu@collabora.com> wrote:

    If $CC_BUILD is not set, configure defaults to GCC for some
    of its tests causing clang builds to use a mixture of the
    two compilers instead of using just clang consistently.
    [snip]

    Thanks!

    Looks like Polynomial-C applied this as https://github.com/gentoo/gentoo/commit/355c5b5715ffcf787c421d03209642d2823cf1f7 <https://github.com/gentoo/gentoo/commit/355c5b5715ffcf787c421d03209642d2823cf1f7>.

    FWIW, normally we don't post individual package patches
    to this ML, but it's a good question as to.. where they should go
    if people want to use git send-email/a ML workflow.

    Right now, sometimes people send them to gentoo-proxy-maint
    (the list) which the proxy maintainers team that handles
    most user contributions looks at, but I'll be honest and say
    our workflow isn't really optimised for it given it's used
    pretty infrequently.

    Makes me wonder if we should rename the list
    or have a separate one (gentoo-patches?).

    (Or just use that list and make sure people CC
    maintainers as you did here?)

    Best,
    sam

    --Apple-Mail=_24EF3F33-1CDF-4AEF-9F39-09938F0A96E7
    Content-Transfer-Encoding: quoted-printable
    Content-Type: text/html;
    charset=us-ascii

    <html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""
    <div class="">On 7 Jan 2022, at 13:08, Adrian Ratiu &lt;<a href="mailto:adrian.ratiu@collabora.com" class="">adrian.ratiu@collabora.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">If $CC_BUILD is not set,
    configure defaults to GCC for some<br class="">of its tests causing clang builds to use a mixture of the<br class="">two compilers instead of using just clang consistently.<br class=""></div></div></blockquote><blockquote type="cite" class=""><div class="
    "><div class="">[snip]</div></div></blockquote></div><br class=""><div class="">Thanks!</div><div class=""><br class=""></div><div class="">Looks like Polynomial-C applied this as&nbsp;<a href="https://github.com/gentoo/gentoo/commit/
    355c5b5715ffcf787c421d03209642d2823cf1f7" class="">https://github.com/gentoo/gentoo/commit/355c5b5715ffcf787c421d03209642d2823cf1f7</a>.</div><div class=""><br class=""></div><div class="">FWIW, normally we don't post individual package patches</div><div
    class="">to this ML, but it's a good question as to.. where they should go</div><div class="">if people want to use git send-email/a ML workflow.</div><div class=""><br class=""></div><div class="">Right now, sometimes people send them to gentoo-proxy-
    maint</div><div class="">(the list) which the proxy maintainers team that handles</div><div class="">most user contributions looks at, but I'll be honest and say</div><div class="">our workflow isn't really optimised for it given it's used</div><div
    class="">pretty infrequently.</div><div class=""><br class=""></div><div class="">Makes me wonder if we should rename the list</div><div class="">or have a separate one (gentoo-patches?).</div><div class=""><br class=""></div><div class="">(Or just use
    that list and make sure people CC</div><div class="">maintainers as you did here?)</div><div class=""><br class=""></div><div class="">Best,</div><div class="">sam</div></body></html>
    --Apple-Mail=_24EF3F33-1CDF-4AEF-9F39-09938F0A96E7--

    -----BEGIN PGP SIGNATURE-----

    iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmHZHUVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDvjJgf/UKbNz3x3skpjff/As1l5Fe6uKoP/Lw/0ZfdJotmwNxO7Xrhf3550SvTE iY4WVHOZ24e+5KAeurqIapgxKfMxpRPIsueMd51vXwp79trkmY2d9ww4SO6XAhvk IPijE7dq7zWVSFUhaDmWgV96HLj549BviWGCm4OzV/f3gu3SlwKg5XMA3caE8P5e 1cU7pEdBNYuUv5UWhFPsuhrDFeEhPmBtE4oO1x80KlSQocYLQ8JCzzmyHO4Lr9QS ODvTK7TvjEtc9f24e19RJFXJQULCxffEZjMi8LllnXIgoVDnbG7Pxw1ofCeFGzAU yLKTir0B6QrplIxK2ly9sP3MDHslgA==
    =i2ac
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anna Vyalkova@21:1/5 to Sam James on Sat Jan 8 07:20:01 2022
    On 2022-01-08 05:12, Sam James wrote:
    FWIW, normally we don't post individual package patches
    to this ML, but it's a good question as to.. where they should go
    if people want to use git send-email/a ML workflow.

    Sending patches directly to maintainer(s) also works for git send-email workflow.

    Makes me wonder if we should rename the list
    or have a separate one (gentoo-patches?).

    I think gentoo-patches will only be useful if it's low-traffic,
    otherwise devs may be unwilling to subscribe and pay attention to it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joonas Niilola@21:1/5 to Sam James on Mon Jan 17 17:20:01 2022
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------JIpUp8ojHtT2iRQbpeAl0PMA
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 8.1.2022 7.12, Sam James wrote:

    FWIW, normally we don't post individual package patches
    to this ML, but it's a good question as to.. where they should go
    if people want to use git send-email/a ML workflow.

    Right now, sometimes people send them to gentoo-proxy-maint
    (the list) which the proxy maintainers team that handles
    most user contributions looks at, but I'll be honest and say
    our workflow isn't really optimised for it given it's used
    pretty infrequently.

    Makes me wonder if we should rename the list
    or have a separate one (gentoo-patches?).

    (Or just use that list and make sure people CC
    maintainers as you did here?)

    Best,
    sam

    I don't think setting up a new mailing list purely for patches will
    benefit much. It all comes down to who's gonna merge the contributions,
    and Github/bugzilla are definitely easier in that regard. I suggest
    opening a bug like normally, and then sending the .patch to the
    maintainers directly via e-mail with bug #nr linked either in Subject or
    git message body.

    -- juippis

    --------------JIpUp8ojHtT2iRQbpeAl0PMA--

    -----BEGIN PGP SIGNATURE-----

    iQGTBAEBCgB9FiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAmHllPRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjIACgkQc4OUK43A aWLg5Qf/RAdaAYcg2FTkagGz7KJ9bIkk4YhefNOEXBteoV/E/TLTqw0hMJ3koc5o SRvI0QGipUZTT6ngklKsOa2vX019sY/fAel32quFtkXYHBOZn1m9nSG6BWYECOe4 VBb/aPkLy0VNapFOa4kW4fdDb0BXRebVXZnQJPlvg813dVcxu/9cR8uMS2EMqJsk Ko/MBZ7ye0eckFnnZ36dvENNfZmqDyBOFukNQw8iyoQcNRpSXCVrBzPD8EIhzjMd ngAApOlRMQt9OQtpg5cYTGYLa1L7n4/X/RAVuLcOba1E33nBD063Mw0r+n2Ph4qM yYjTTtEKpDLgj40n9ceP0gC3MlrEmg==
    =J12i
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)