Date: Sat, 16 Sep 2023 15:20:37 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Brooks Davis <brooks@freebsd.org> Cc: ports@freebsd.org Subject: Re: Wow: Building the likes of devel/llvm16 now requires building rust first (when rust is out of date). . . A WORKAROUND Message-ID: <20230916152037.c19fb477397a249d7317f1fd@dec.sakura.ne.jp> In-Reply-To: <ZQR6cAH1qykqdU9Y@spindle.one-eyed-alien.net> References: <5620735A-FB8A-4AFE-B4E4-32D0D8D58962@yahoo.com> <6557AA51-D4E2-4E30-B3B4-BA0B356D5343@yahoo.com> <20230915183739.e6070e828ef769f611d78bc9@dec.sakura.ne.jp> <ZQR6cAH1qykqdU9Y@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Sep 2023 15:38:24 +0000
Brooks Davis <brooks@freebsd.org> wrote:
> On Fri, Sep 15, 2023 at 06:37:39PM +0900, Tomoaki AOKI wrote:
> > On Thu, 14 Sep 2023 21:32:20 -0700
> > Mark Millard <marklmi@yahoo.com> wrote:
> >
> > > On Sep 13, 2023, at 23:20, Mark Millard <marklmi@yahoo.com> wrote:
> > >
> > > > Note: py39 is in use in my context.
> > > >
> > > > Building devel/llvm16 requires building textproc/py-recommonmark@py39
> > > > Building textproc/py-recommonmark@py39 requires building textproc/py-sphinx@py39
> > > > Building textproc/py-sphinx@py39 requires building www/py-requests@py39
> > > > Building www/py-requests@py39 requires building net/py-urllib3@py39
> > > > Building net/py-urllib3@py39 requires building security/py-openssl@py39
> > > > Building security/py-openssl@py39 requires building security/py-cryptography@py39
> > > > Building security/py-cryptography@py39 requires building devel/py-setuptools-rust@py39
> > > > Building devel/py-setuptools-rust@py39 requires building lang/rust
> > > >
> > > > Building devel/llvm16 and the like just got more
> > > > resource intensive for those not already building
> > > > lang/rust . Building lang/rust in my context uses
> > > > system-clang ( not a devel/llvm* ). So no loop in
> > > > my context.
> > > >
> > > > I normally build rust anyway. But other folks may
> > > > have been avoiding such.
> > > >
> > >
> > > I have the file (for other reasons):
> > >
> > > /usr/local/etc/poudriere.d/make.conf
> > >
> > > and I added to it:
> > >
> > > .if ${.CURDIR:M*/devel/llvm*}
> > > OPTIONS_UNSET=DOCS
> > > .endif
> > >
> > > This overrides the "always on" for DOCS for
> > > the various devel/llvm* . (In more complicated
> > > contexts += would be appropriate i order to
> > > allow multiple assignments to accumulate.)
> > >
> > > This stopped the recommonmark use and, so, stopped
> > > the sequence of dependencies leading to lang/rust
> > > being required.
> > >
> > > This appears to do more than whatever John F Carr did
> > > to get it to report in his context:
> > >
> > > ===> The following configuration options are available for llvm17-17.0.0.r4:
> > > . . .
> > > DOCS=off: Build and/or install documentation
> > > . . .
> > >
> > > (Likely normal style options file content was involved.)
> > >
> > > I did not make any such "normal style" OPTIONS changes and the
> > > log file for my build attempt reported:
> > >
> > > ---Begin OPTIONS List---
> > > ===> The following configuration options are available for llvm17-17.0.0.r4:
> > > BE_AMDGPU=on: AMD GPU backend (required by mesa)
> > > BE_WASM=on: WebAssembly backend (required by firefox via wasi)
> > > CLANG=on: Build clang
> > > COMPILER_RT=on: Sanitizer libraries
> > > DOCS=off: Build and/or install documentation
> > > EXTRAS=on: Extra clang tools
> > > FLANG=off: Flang FORTRAN compiler
> > > GOLD=on: Build the LLVM Gold plugin for LTO
> > > LIT=on: Install lit and FileCheck test tools
> > > LLD=on: Install lld, the LLVM linker
> > > LLDB=on: Install lldb, the LLVM debugger
> > > MLIR=on: Multi-Level Intermediate Representation
> > > OPENMP=on: Install libomp, the LLVM OpenMP runtime library
> > > POLLY=on: Polyhedral loop and data-locality optimizer
> > > PYCLANG=on: Install python bindings to libclang
> > > STATIC_LIBS=on: Install static libraries (does not effect sanitizers)
> > > ====> Options available for the single BACKENDS: you have to select exactly one of them
> > > BE_FREEBSD=off: Backends for FreeBSD architectures
> > > BE_NATIVE=off: Backend(s) for this architecture (X86)
> > > BE_STANDARD=on: All non-experimental backends
> > > ===> Use 'make config' to modify these settings
> > > ---End OPTIONS List---
> > >
> > > The --PLIST_SUB-- section ended up listing: PORTDOCS="@comment
> > > and: DOCS="@comment " NO_DOCS=""
> > > but still listed: DOCSDIR="share/doc/llvm17"
> > >
> > > The --SUB_LIST-- section ended up listing: DOCS="@comment " NO_DOCS=""
> > > but still listed: DOCSDIR=/usr/local/share/doc/llvm17
> > >
> > >
> > > FYI, without rust having been built, my first ever build
> > > of llvm17 (not reporting on the 49 prior poort->package
> > > builds before devel/llvm17 started):
> > >
> > > [00:43:30] Finished devel/llvm17@default | llvm17-17.0.0.r4: Success
> > >
> > >
> > >
> > > FYI:
> > >
> > > 5.14.1.3 Default Options in:
> > >
> > > https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-options
> > >
> > > reports the always-on status for DOCS (and some more)
> > > but not the way(s) to override that status for specific
> > > ports. It seems that only some ways actually change the
> > > status to off --and I've found one such.
> > >
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> >
> > So is it easily possible to docs of llvm ports to be separate ports?
>
> No. Docs are built as part of each enabled component.
>
> -- Brooks
Not sure it's possible or not (maybe impossible now), if multiple
packages can be generated by single port on single build,
if DOCS option is set, generate 2 pkgs
llvm(major)-(full-ver)_(rev),(epoch).pkg
llvm(major)-doc-(full-ver)_(rev),(epoch).pkg
if not, generate
llvm(major)-(full-ver)_(rev),(epoch).pkg
only,
set DOCS by default for pkg build cluster and anyone who do not want
suffer from rust hell can unset DOCS and install docs pkg from official
repo.
--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230916152037.c19fb477397a249d7317f1fd>