Man make.conf say: WITHOUT_MODULES (str) Set to a list of modules to exclude from the build. This provides a somewhat easier way to exclude modules you are certain you will never need than specifying MODULES_OVERRIDE. This is applied after MODULES_OVERRIDE. I use it to not build some kernel modules. These ports fail/show warning about WITHOUT_MODULES. lang/tcl86 - warning: /!\ WARNING /!\ WITHOUT_MODULES is unsupported, use WITHOUT=MODULES on the command line, or one of these in /etc/make.conf, OPTIONS_UNSET+=MODULES to set it globally, or lang_tcl86_UNSET+=MODULES for only this port. www/apache24 - error: ===> apache24-2.4.29 : Error from apache.mk. WITH(OUT)_MODULES has been removed, use www_apache24_(UN)SET. *** Error code 1 What I should do to build ports and not build some kernel modules?
This suggests that MODULES is not a usable option name for a port (lang/tcl86) and WITHOUT_MODULES is not a usable variable name within ports/Mk machinery (bsd.apache.mk). Is this expected / wanted?
Yes. I read man make.conf and set WITHOUT_MODULES=.... in /etc/make.conf. Now this broke apache24. Some one from FreeBSD or ports team should rename or add some hacks to avoid same name usage conflict.
I ran into this issue when upgrading from 10.4 to 11.1 as well when doing the post upgrade package/port reinstall.
is the problem with apache24-2.4.33 still?
(In reply to Jochen Neumeister from comment #4) root@rimwks# cd /usr/ports/www/apache24 root@rimwks# make ===> apache24-2.4.33 : Error from apache.mk. WITH(OUT)_MODULES has been removed, use www_apache24_(UN)SET. *** Error code 1 Mine /etc/make.conf contain: WITHOUT_MODULES+= xfs zfs # Other drivers WITHOUT_MODULES+= bktr bktr_mem cardbus cbb cmx exca fdc firewire pccard rp scd smapi xenhvm and more WITHOUT_MODULES+=, but at least one is enough to reproduce.
This is not apache specific thing. At least lang/tcl86 affected, probably some other ports too: comms/nmealib databases/mysql-udf databases/tdbc devel/linux-kernel dns/powerdns editors/emacs-devel graphics/ImageMagick ftp/proftpd lang/newlisp-devel lang/newlisp lang/tcl85 lang/tcl86 net-mgmt/fetchconfig textproc/docbook-xsl x11-wm/e-modules IMHO better solution is rename *MODULES to *KMODULES or *KERNEL_MODULES in make.conf file and allow to use MODULES in ports. Another way is forbid MODULES use in ports.
Or put everything related to the source build in /etc/src.conf.
Looking at it, this has always been a problematic thing... The variables in /etc/make.conf affect both base and ports. If modules happen to have overlapping names this will lead to unexpected behavior. As man src.conf says "source build options" that is where I would expect that we document WITH_/WITHOUT_MODULES. Should we assign this to docs@? Additionally, I think we should mark both WITH_ and WITHOUT_MODULES as UNSUPPORTED in Mk/bsd.sanity.mk. Now there's checks that emit the warning as seen in the opening Description for lang/tcl86. For the www/apache24 ports we set then to IGNORE in the ports framework.
And references to /etc/make.conf in handbook too https://www.freebsd.org/doc/handbook/kernelconfig-building.html
A commit references this bug: Author: gahr Date: Tue Mar 27 14:24:26 UTC 2018 New revision: 465706 URL: https://svnweb.freebsd.org/changeset/ports/465706 Log: lang/tcl85, lang/tcl86: remove MODULES option MODULES conflict with WITHOUT_MODULES from make.conf (see bug 226557). Moreover, they don't require any additional dependencies and their cost in terms of size is small wrt the total size of these ports. PR: 226557 Changes: head/lang/tcl85/Makefile head/lang/tcl85/pkg-plist head/lang/tcl86/Makefile head/lang/tcl86/pkg-plist
Note that like the warning says, using WITH_opt / WITHOUT_opt is not supported. It WILL NOT DO ANYTHING. Especially, it will not enable or disable an <opt> option. So the update to tcl was unwarranted.
Well, I have been kind of willing to remove this option anyway - if you look at the alpha lang/tcl87, it doesn't have it. I think this bug popped up just at the right moment to make me decide to eventually do it. It won't do any harm.
*** Bug 227037 has been marked as a duplicate of this bug. ***