Even with minimal defaults being equivalent to pre-compiled packages, you still gain a snappier system - just because it was your processor doing the compiling, and not some unknown processor elsewhere.
Even with minimal defaults being equivalent to pre-compiled packages, you still gain a snappier system - just because it was your processor doing the compiling, and not some unknown processor elsewhere.
This has nothing to do with it. The output of the compiler will be the same no matter which processor is used to compile it. The instructions are the same. There is no difference. That is why the binary can run on any hardware you are using that is compatible.
The binary will run, but it still needs to find the correct hardware address at which to get loaded, and run. If you take a look at
# kldstat output on two different systems (say, an i7 and a Ryzen 7), you will notice that the .ko files' starting addresses are different. Even if the binary loads and runs with identical instructions, 'home' processor will do a better job handling its own compilations than 'away' processor. This is why compiler and makefile flags are set to a minimum needed.Yeah, I looked at Gentoo and its Portage system back in the day when I was getting frustrated with dependency hell in Linux... and I decided that FreeBSD's Ports system is just much better organized...
For a fair comparison, you'd have to have at least 4 processors, 3 from same generation: say, a Threadripper, a Ryzen 5, and an i5. The 4th one would be an older i5. They all would have the same amd64 instruction set. Say the Threadripper did the compiling, since it's the mightiest, and can do the job the fastest. Ahh, I'm getting too lazy for this, I guess I'll let Phoronix answer that question instead of me, and have more recent (and therefore relevant) data.
. It was fun while it lasted, but I can't do it. I tried, really, but everything takes forever to configure and build and while I might mess with those compile options for a single program, I'm not keen on trying them out for dependency trees. I installed a bunch of ports and was all smug, "I got this", when I went about how to update the lot... ugh, just not my cup of tea. I'm comfortable with packages and pkg update && pkg upgrade - why mess with it if it ain't broke? I do feel like if I was about to be stranded on a desert island and was only given port access and no binary packages, I could get a system running though, thanks to y'all's tips .Yes. Different processors handles the same instructions faster or slower but that has nothing to do with the output of the compilers. The instructions are the same whether you use ports or packages!
I disagree with that, this makes fine-tuning difficult to debug if something goes wrong. I'd rather accept the defaults presented by make.conf and know that if something did not compile, I can isolate the problem to the specific port. More work, I know, but I'm willing to live with that.
That's not my reasoning... My reasoning has more to do with the fact that circular dependencies are easier to debug/resolve if I do per-port options. Also - there's like, 3 different options for Kerberos in ports, but it's impossible to specify just one for all ports - some ports specify just the one from base system, some offer all 3 options, and some specify just one option that is NOT the one from the base system.
That's true and that's what I meant with
pkg defaulting to quarterly and portsnap to latest).In make.conf:
OPTIONS_UNSET+=KERB_GSSAPI
OPTIONS_UNSET+=KERBEROS
OPTIONS_UNSET+=GSSAPI_BASE
OPTIONS_UNSET+=GSSAPI_HEIMDAL
OPTIONS_UNSET+=GSSAPI_MIT
OPTIONS_UNSET+=GSSAPIIf you mix quarterly ports and packages you won't have version differences, that is correct. The reason to use ports however is that you want to change things. That may bring other problems. For instance, you may choose to leave out Pulseaudio for your audio applications for good reasons by unchecking it in ports. If later on you install, say, a package containing a webbrowser there is a good chance that Pulseaudio will be back...bsduck said:
When I run
portmaster www/youtube_dl it gathers dependency info, has me check the options I want for each one presented, then when that process is completed it presents me with a screen of what programs are to be installed with the option to go or no, or to only allow certain programs to be built if I chose not to go with what it recommends: pkg install www/youtube_dl. But I also get a custom desktop built from ground up by me.:
For portmaster users:
# sh
# portmaster -o lang/python38 python37
# REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
# pkg delete -f "*py37*"
# portmaster $REINSTALL
# REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f 1 | sort -u)
# portmaster $REBUILD
# REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' | sort -u)
# portmaster $REBUILD2 # pkg delete -f "*py37*"Yeah, I actually noted that one, and v. 7 is the one I compile ahead of time, before it gets pulled in as a dependency. Then, when I compile everything else, the ports notice that imagemagick v7 is installed, and don't harass me to install v. 6