Compiling, options, and dependencies (make, compiler)

I wouldn't recommend it [editing Makefiles], aside from experimentation. But the FreeBSD ports system /usr/ports/Mk provides a myriad of wonderful "KNOBS" to accomplish most anything one could hope for, and all via make.conf(5)! :)--Chris

I wonder if devel/gmake can be replaced with gmake-lite that is called from ports' Makefile's by editing /usr/ports/Mk/Uses/gmake.mk. gmake seems to draw in a lot of dependencies and a perpetual list of options (that don't seem to add any functionality to FreeBSD) when building, if I'm not mistaken. The problem may not be with gmake itself.

Some builds by gmake can be replaced with make with no problems; but many imake, cmake, and gmake meant builds will fail by using regular make. Can /usr/ports/Mk/ be adjusted to override specific ports Makefile's dependencies or options?

Also I'd like to know if clang is always being called instead of gcc, regardless of which make is used, or how to override the options if another compiler is called.

What I'm trying to do here is streamline the build options, and make as much native to FreeBSD. It turns out that I've done builds that last half a day and they failed, or had so many options, that tuning them wrong, causes circular dependencies to pop up. I've found out that many dependencies weren't needed, they were just called on to complete GNU or GCC dependencies, not dependencies that make FreeBSD programs functional.
 
What dependencies does devel/gmake have? Both the Makefile and pkg info -d gmake show very little.

There are ways to override the compiler specified for a port, but they tend to be counterproductive because a port will not specify a particular compiler unless it is needed.

This might be an X/Y problem. Please give a specific example of the problem you are trying to solve.
 
I wonder if devel/gmake can be replaced with gmake-lite that is called from ports' Makefile's by editing /usr/ports/Mk/Uses/gmake.mk.
Don't do that -- NO, NO!
You should NEVER edit the FreeBSD ports(7) environment that way. You'll taint the system, and end up with error messages that make no sense at all, and may be unresolvable. Requiring you to essentially wipe your whole ports, or src, and have to start again, fresh.
Probably not at all what your hoping for. :)
However, you can add all kinds of madness to your make.conf(5) file -- remember my mentioning that to you in your quoted text? :) Point being; all those goodies in /usr/ports/Mk are there for port Maintainers, and for users to utilize when building ports on their system. Port Maintainers use them in the Makefile they create for the port(s) they maintain. Users, can utilize many of those same KNOBS within their make.conf(5) file, or at the command-line, via a -D switch. Honestly, I would end up writing an entire book here, attempting to explain it all. My recommendation to you is; have a good look at the make.conf(5) page, you might even do well to read the make(1) man(1) page. Then you could also read through some of the ports(7) Makefiles to get an idea on how those KNOBS are used.
I'm afraid there's no "silver bullet" here. It's going to take some time, and experimentation on your part. That's how everyone "get's the hang of it". :)

Also I'd like to know if clang is always being called instead of gcc, regardless of which make is used, or how to override the options if another compiler is called.
Clang is the future, resistance is futile.
Maybe not what you wanted to hear, and I do understand. I fought it pretty heavily, and successfully got GCC in Base, as the default compiler (c, cc, c++, ...). The choice of compiler is greatly influenced by the $PATH env. [typically] meaning; that what's in /, and /usr will be found first, and subsequently, used. So the biggest part of determining what gets chosen, will depend on what environment you have created, when building, and installing "world". You can influence this decision, by modifying make.conf(5), and src.conf(5).
This is how I accomplished making (GNU)GCC the base compiler:
Code:
#make.conf
WITHOUT_CLANG=true
FAVORITE_COMPILER=gcc
Code:
#src.conf
WITH_GCC=true
WITH_GCC_BOOTSTRAP=true
WITH_GNUCXX=true
WITHOUT_CLANG_BOOTSTRAP=true
WITHOUT_CLANG=true
WITHOUT_CLANG_IS_CC=true
I was then able to install additional versions of GCC, and Clang, from ports.
In the end, IMHO it was more work, than it was worth. Both using this setup, as well as honing everything to work as desired. But I am very glad I did it. It ultimately gave me much greater insight into the (FreeBSD) system, as a whole. Not that I wasn't already keenly aware. But FreeBSD is really in a state of flux, right now, and after years of working with things the way they were and never having many changes in the toolchain. With the advent of Clang being the default in Base. Sort of turned everything up-side-down. So it was an effort well taken.

Sorry for replying in chunks. But I have a lot on my plate, right now. Hope this helps!

Best wishes, sidetone.

--Chris
 
Thanks for your replies.
It's true that many compiles will break by using the wrong make, but there are many that are still compatible with bsdmake. Many weren't OS specific, and I think it was just that Linux had them imported first. So why not use Clang with whichever make command.

I might be mistaken. It may have been when gmake dependencies occasionally called in gcc, which is fine for some, but that is too bulky for my preferences when it called in too many options. Doing a make rmconfig-recursive, not only reset options for the program, but it did it for gcc and gnu dependencies too. It's possible they may have corrected some of these excessive dependencies recently, because if it's not my perception, the build options and dependencies seem to be improved. (It's possibly my perception, because I could have figured out which options weren't needed that called in 50 options, instead of 10) We may disagree on whether to use the program's called for compiler, that's fine, but when it works, I'd rather use the programs that comes with FreeBSD.

Please give a specific example of the problem you are trying to solve.
One example is that many ports call in HAL when DEVD is available, when it could be automatically set according to which FreeBSD version is running, or chosen by a radio option. I had to tinker around to see this, and could remind the maintainers.

Chris_H
That's a fine answer. I'm tinkering with my system, and I do fresh extracts of ports or jails, without messing up my system; maybe that's a way to learn. Experimenting this way seems to run smoothly. If I think I can make something run better, it's good to inform the maintainers, and let them figure out if it works better for all purposes.

Clang is the future, resistance is futile... With the advent of Clang being the default in Base. Sort of turned everything up-side-down. So it was an effort well taken
I was trying to say Clang was a good thing. The only problem in my opinion is a temporary one, that ports haven't been adapted to make the best use of it. Clang may even be more compatible, by using the various make commands.

I'd rather use Clang, because it already integrates through FreeBSD, and no options have to be set. I think GCC has a lot of repetition that has to be set in its options and dependencies (some for hardware), when FreeBSD already has these capabilities in it's base.
 
Back
Top