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



## tOsYZYny (Sep 29, 2020)

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?


----------



## mark_j (Sep 29, 2020)

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.


----------



## T-Daemon (Sep 29, 2020)

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.


----------



## Mjölnir (Sep 29, 2020)

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).


----------



## olli@ (Sep 29, 2020)

mjollnir said:


> either you do not use the _latest_ ports tree via portsnap(8), but the _quarterly_ via svnlite(1)


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.


----------



## psa (Sep 30, 2020)

As mjollnir says, build with poudriere(8). The port build options are set with poudriere-options(8)


----------



## Zvoni (Oct 1, 2020)

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")


----------



## diizzy (Oct 1, 2020)

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)).


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

For instance


----------



## sidetone (Oct 1, 2020)

Individual ports can also be set from make.conf:

```
x11-drivers_xorg-drivers_SET=AMDGPU ATI
net-im_libpurple_UNSET=GSTREAMER
```

You would have something like:


```
multimedia_vlc_SET= X264 X265
```


----------



## olli@ (Oct 1, 2020)

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.


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).


----------



## jmehr (Nov 12, 2020)

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!


----------

