Passing target to source Makefile

Russell Haley russ.haley at
Thu Aug 4 06:39:27 UTC 2016

On Fri, Jul 22, 2016 at 1:53 AM, Jan Beich <jbeich at> wrote:
> Russell Haley <russ.haley at> writes:
>> 1) It does not use the recommended "freebsd" target. While the port
>> overlays many of the same options, the system doesn't seem to respect
>> the targets and also performs the installation without specifically
>> calling the "install" target.
> Try adding ALL_TARGET=freebsd. INSTALL_TARGET already defaults to
> "install" and then the port appends extra steps via post-install.
>   $ make -V ALL_TARGET -C lang/lua53
>   all
>> The current supported version of Lua is 5.3.  While I can see the need
>> to install past versions using explicit naming, it is my opinion that
>> the current version should be installed as Lua, not luaXX.
> Say, a port looks for Lua 5.1 headers. If Lua 5.3 is installed without
> suffix the port may find wrong headers first. And fixing include order
> isn't always trivial with complex build systems. But -isystem as used by
> USES=localbase partially alleviates that.

Hi There Jan. I'm very curious about ports and dependancies so I'd
like to question you on this point further. I have just run into
issues between arm-none-eabi-gcc versions due to an upgrade in
10.3-RELEASE p5. It forced me to look at the gcc compiler versions and
in the devel/ port tree. From Freshports

arm-none-eabi-gcc - This port is the current FreeBSD  gcc version at 5.3.0
arm-non-eabi-gcc492 - This port is the previous FreeBSD gcc release at 4.9.2

This is what I would consider the correct pattern for Lua as well. The
current running version of the interpreter or compiler should either
be symlinked or named without the version number. If a developer or
user requires a specific older version, then that version must be
manually installed by it's version number and linked to the correct
paths. Is there any reason why forcing all Lua installation to use the
numbered binary is preferred?

I seem to remember Debian had some sort of tool for managing symlinks
to different versions of a library but I can't find it off hand. I
wonder if there is some sort of mechanism within pkgng and the bsd
makefiles to handle this type of scenario? Again, it matter little in
terms of desire to change the port as I build it myself. I'm just
wondering for curiosity sake.


More information about the freebsd-ports mailing list