svn commit: r515803 - head/devel/bazel

[Gleb Popov]

On Wed, Oct 30, 2019 at 10:27 AM Mathieu Arnold <mat at freebsd.org> wrote:

> On Tue, Oct 29, 2019 at 09:33:10AM +0400, Gleb Popov wrote:
> > My approach at least provide a stable binary package, and actually a
> > way to build from source too - it just don't follow usual `make
> > install` procedure.
>
> The problem with that is that comes from some false assumption.  It is
> not *your* port.  As such it is not ok to have some obscure steps that
> nobody else knows about.  Ports belong to everyone, and anyone should be
> able to update a port.  If you have to do some arcane thing that is not
> in the normal procedure to build a port, like pregenerating some binary
> package (which is what the port is supposed to do in the first place),
> then you are doing it wrong.
>

Actually, there are many examples in our ports tree that use "arcane
things". Uses/cabal.mk has auxiliary targets to generate large portions of
Haskell ports Makefiles. You can, in theory, write them manually, but this
is exceptionally tedious.
I believe, something like that is also implemented for Go and Rust ports.
The same thing for wine-i386.
>From my experience, it is not that often when you can update the port just
by bumping {PORT,DIST}VERSION. In most cases you still need to do "obscure
steps", depending on your understanding of obscurity. Some of which are
documented and some are not. Speaking for myself, I did documented cabal.mk
(although not in Porter Handbook) and also would have document TensorFlow's
Makefile, would the port be finished.

Again, I agree that making TensorFlow build the usual way is better than
any other approach, but we can see that maintainer can't keep up with it.
And no wonder - it is extermely large piece of software with unfriendly
build system. So, I still lean toward prepackaged approach + documenting
the procedure.


> --
> Mathieu Arnold
>