Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Jul 2017 09:37:34 +0200
From:      "Klaus T. Aehlig" <aehlig@linta.de>
To:        Yuri <yuri@rawbw.com>
Cc:        "ports@freebsd.org" <ports@freebsd.org>
Subject:   Re: Anybody knows how to patch tarballs that bazel extracts?
Message-ID:  <20170717073734.GC2012@howard.linta.de>
In-Reply-To: <333c214c-4551-8f7d-9de4-ff4dabd33ab3@rawbw.com>
References:  <333c214c-4551-8f7d-9de4-ff4dabd33ab3@rawbw.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> Bazel (devel/bazel) based projects tend to fetch tarballs directly. 
> WORKSPACE can be patched to change the fetch URL to one in 
> /usr/ports/distfiles. However, what to do when the contents of tarballs 
> need to be patched?

Unfortunately, there is no real good bazel way to do this. It was
discussed serveral times to add a patch option to the new_http_archive
rule, but unfortunately, it was never implemented. Such discussion is
best done at bazel-dev@googlegroups.com.

If you want to solve the problem within bazel, you can, of course,
always write a skylark-rule that, given a tar ball, unpacks it, applies
the patches, and repacks it.

Fortunately, for the ports tree, we have a better way to solve the
problem. The ports infrastructure allows to extract all the relevant
tar balls into separate directories under ${WRKDIR}, and also patch
them there. Then, you can patch WORKSPACE to point to a new_local_repository
rather than a new_http_archive.

However, even with that approach, you should be aware that you're
embedding the relevant dependencies rather than using them from
${LOCALBASE}. So, in the long run, it might be desirable to patch the
relevant targets in the BUILD files using those external resources to
point to ${LOCALBASE}. Maybe, one could even lobby for a new_local_library
WORKSPACE rule at bazel-dev@googlegroups.com. But that's all long-term
perspective...

Best,
Klaus



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170717073734.GC2012>