How can I streamline building ports, avoid prompts, but whilst still retaining control over options?

T

tOsYZYny

As an example, I am building vlc with x264 and x265 support. I need to answer questions for all of its dependencies which is quite cumbersome. I have tried using portmaster and that appears to help with the configuration, but I'd still like to be able to do it in a non-interactive way.

This shows how to do a batch build, but it seems you lose control over options.
https://unix.stackexchange.com/ques...id-the-prompts-when-installing-a-freebsd-port

Is it possible to get a list for all packages and then centralize that configuration in one place?
 
Have you read ports(7)?
You can recursively ask make to prompt for all configuration settings (which are stored) and then never have to answer them again.
make config-recursive
Easy-peasy.
If you don't want to do that you can manually edit the configuration file /etc/make.conf. Again, read the manual.
 
If multimedia/vlc is the only port you want to modify options, run make config for it, run afterwards make install clean BATCH=1. If following dependencies require also configurations changed use the make(1) target mark_j suggested. If BATCH is set in /etc/make.conf, then, in case you want to modify options, you need to run the config or recursive config target for the port before the build.
 
Also note ports-mgmt/lsknobs & ports-mgmt/portconf. To get an overview, you can do psearch -c ports-mgmt | less (install ports-mgmt/psearch 1st).

To build from ports(7) is not recommended unless you change configuration knobs; i.e. for dependent ports with default configuration, you can use packages, which implies the ports tree & package repository versions must match. Thus if you mix your own ports builds with packages from the official repositories,
  • either you do not use the latest ports tree via portsnap(8), but the quarterly via svnlite(1)
  • or you use the latest packages: create a /usr/local/etc/pkg/repos/FreeBSD.conf & edit.
  • Do yourself a favour and don't build on the host, but jailed with poudriere(8) or synth(1).
 
mjollnir said:
Click to expand...
My recommendation is net/svnup, see the svnup(1) and svnup.conf(5) manual pages.
It’s easy to configure and requires less resources than svnlite. The “Examples” section in the manual page shows how to fetch the current ports tree (a.k.a. “head”). This is also included in the sample file included with the port. It can easily be changed to fetch a quarterly ports tree instead.

By the way, personally I always build everything from ports myself (I have my own scripts for doing that), but this is certainly not recommended for most users.
 
Agree with mjollnir regarding ports-mgmt/poudriere.
Set your options once (!!) with poudriere, and with any update of the port, you only have to set "new" options and/or new dependencies (py37 being the current "winner")
 
Keep in mind that svn is going away in favour of git, this however poses a "chicken or the egg"-problem right now as there's no git client in base.
In addition to that you can set options using make.conf both globally and on port level and you can also set CPU optimization to match your CPU more closely (example is for aarch64 (arm64)).

Code: 
CPUTYPE?=cortex-a53
OPTIONS_UNSET=DOCS EXAMPLES NLS MANPAGES TEST
OPTIONS_SET=LTO

For instance :-)
 
Individual ports can also be set from make.conf:
Code: 
x11-drivers_xorg-drivers_SET=AMDGPU ATI
net-im_libpurple_UNSET=GSTREAMER

You would have something like:

Code: 
multimedia_vlc_SET= X264 X265
 
diizzy said:
Keep in mind that svn is going away in favour of git, this however poses a "chicken or the egg"-problem right now as there's no git client in base.
Click to expand...
ISTR there are plans to have git commits being made available through svn, so svn clients like net/svnup will continue to work for a certain transition period. I’m also quite positive that it shouldn’t be too difficult to create a “net/gitup” port as a drop-in replacement, just like svnup was meant to be an easy-to-use replacement for cvsup (specifically for non-developers).
 
I’ve been working on a “gitup” replacement for net/svnup and I’m close to having a fully functioning “git clone” prototype. Once that’s ready, the next step is to implement the “git pull” functionality with as small a footprint as possible and then open it up for wider testing.

Stay tuned!
 
You must log in or register to reply here.
Back
Top