Discussion:
Passing target to source Makefile
(too old to reply)
Russell Haley
2016-07-21 06:03:48 UTC
Permalink
Hi there,

I've been able to hack up the Makefile for an update of lua53 but the
one thing still missing is the ability to pass a target for the source
Makefile (i.e. lua's Makefile, not the ports Makefile). I need to pass
in "freebsd" as per the build instructions for lua.

Also, I can't seem to get make makeplist to work, but I think that's
because the lua makefile is defaulting to install the files (due to
the lack of target) and overriding the makeplist output?

Thanks,

Russell
Carsten Larsen
2016-07-21 18:20:05 UTC
Permalink
Hi Russell,
Post by Russell Haley
I've been able to hack up the Makefile for an update of lua53 but the
one thing still missing is the ability to pass a target for the source
Makefile (i.e. lua's Makefile, not the ports Makefile). I need to pass
in "freebsd" as per the build instructions for lua.
Assuming gnu make is used, do this:

do-build:
${GMAKE} -C ${WRKSRC} TARGET=insert-here
Post by Russell Haley
Also, I can't seem to get make makeplist to work, but I think that's
because the lua makefile is defaulting to install the files (due to
the lack of target) and overriding the makeplist output?
Thanks,
Russell
Russell Haley
2016-07-21 19:25:17 UTC
Permalink
Post by Russell Haley
Hi there,
I've been able to hack up the Makefile for an update of lua53 but the
one thing still missing is the ability to pass a target for the source
Makefile (i.e. lua's Makefile, not the ports Makefile). I need to pass
in "freebsd" as per the build instructions for lua.
Also, I can't seem to get make makeplist to work, but I think that's
because the lua makefile is defaulting to install the files (due to
the lack of target) and overriding the makeplist output?
Thanks,
Russell
Hi Russel,
it is not clear if you try to hack the lag/lua53 port or a different one.
There are perhaps two ways, during configure or as make arg
CONFIGURE_ARGS+= target=freebsd
or
MAKE_ARGS+= target=freebsd
Perhaps you can give the list some more information?
Yes, of course.

TLDR; I think the Lua port needs some love so I'm trying to update it
to the most recent version.

I am trying to develop a cross platform Lua application that will run
in both FreeBSD and Debian. I have had to abandon the FreeBSD lua53
port for the following reasons:

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. This is from memory and *could* be
incorrect, but this is my anecdotal experience. In the end, we will
lose the benefit of any changes made upstream (more on that in a bit).
2) There seems to be lost of "stuff" going on in the port file that
seems unnecessary as the Lua Makefile takes care of most of the
extras.
3) By forcing all Lua installation to use luaXX naming conventions, it
forces the user to have to create work arounds or links to get the
standard interpreter to work by calling "lua" (which is the expected
use case in my opinion). 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.
4) The current Makefile applies -fPIC to some of the platforms, but
not armv6. I require that switch for all platforms and it seems to
work fine on my ARM board (Solid-Run Hummingboard, iMX6/cortex A9).
While it's an easy patch, it adds to the list of reasons to build Lua
myself.

So with that in mind, I have been building and running Lua from git
with no patches. While I can continue in this manner, I thought I
would try to give back to the community if there is interest. Lua is
now on version 5.3.3. I have been able to hack up the ports Makefile
to run "successfully" but it still only calls the default target that
assumes an installation. So, my goals in terms of a ports upgrade are
as follows:

- Update to the latest Lua revision
- Get ports to call the correct targets (the makeargs above looks promising)
- Remove the Lua53 naming convention. Once Lua move to a new major
version, this can be re-implemented and the new Lua version can become
the standard interpreter.
- Add -fPIC to all platforms in FreeBSD
- Use clang and bmake instead of forcing gcc/gmake.

The last item I think is the most difficult as it will require others
to test. However, I have successfully built and run Lua 5.3.2 (testing
5.3.3) using clang and bmake (as well as other libraries such as
luasys and luaxml).

All input is welcome. Again, if this is not where the community wants
to go, it's no big deal.

Please also note that I have made an upstream request to the Lua
community to consider applying a patch to the freebsd target in their
source/Makefile. The patch can be found here:
http://pastebin.com/cUCtWb1w. I don't expect this to happen quickly
however.


Most Sincerely,

Russell
Russell Haley
2016-07-21 21:06:45 UTC
Permalink
Post by Russell Haley
Hi there,
I've been able to hack up the Makefile for an update of lua53 but the
one thing still missing is the ability to pass a target for the source
Makefile (i.e. lua's Makefile, not the ports Makefile). I need to pass
in "freebsd" as per the build instructions for lua.
Also, I can't seem to get make makeplist to work, but I think that's
because the lua makefile is defaulting to install the files (due to
the lack of target) and overriding the makeplist output?
Thanks,
Russell
Hi Russel,
it is not clear if you try to hack the lag/lua53 port or a different one.
There are perhaps two ways, during configure or as make arg
CONFIGURE_ARGS+= target=freebsd
or
MAKE_ARGS+= target=freebsd
Thanks again for this suggestion but I can't for the life of me make
it work. I would normally use ports through svn and try to provide a
patch but I have limited time and tools currently (on vacation) so the
best I can do is provide an archive of my updated port files:

https://drive.google.com/open?id=0B1RmC6WWKtYITWplVElaR0Y0QU0

For a quick look, I have posted the raw Makefile in pastebin (yes,
it's a mess but it's a work in progress):

http://pastebin.com/9KhvEL4R

If I can't make the above variables work then I'll perhaps fall back
to Carstens suggestion, but my preference is for the standard ports
variables.

Again, all help is appreciated.

Thanks,

Russ
Matthew Seaman
2016-07-22 06:58:50 UTC
Permalink
Post by Russell Haley
3) By forcing all Lua installation to use luaXX naming conventions, it
forces the user to have to create work arounds or links to get the
standard interpreter to work by calling "lua" (which is the expected
use case in my opinion). 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.
Is there any possibility of needing to install two different versions of
lua simultaneously? Are there lua consumers that require specific
versions[*]?

If that's so, then a better approach here might be be to copy the way
the python ports work: have a lua meta-port which creates appropriate
unversioned symlinks to the executables from the versioned ports.

Cheers,

Matthew

[*] As I recall, for instance, redis embeds lua-5.2 -- but that's not
really germane to this because redis has imported all the lua code, and
doesn't have any dependencies on exteranl lua.
Jan Beich
2016-07-22 08:53:59 UTC
Permalink
Post by Russell Haley
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
Post by Russell Haley
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.
Post by Russell Haley
4) The current Makefile applies -fPIC to some of the platforms, but
not armv6.
https://svnweb.freebsd.org/changeset/ports/409263
Post by Russell Haley
- Update to the latest Lua revision
Do you mean Mk/bsd.default-versions.mk? lang/lua53 is already at 5.3.3.
Post by Russell Haley
- Use clang and bmake instead of forcing gcc/gmake.
bmake isn't available on FreeBSD 9.3-RELEASE which isn't going to be
EOL'd until the next year. If you mean devel/bmake then I don't see the
benefit compared to devel/gmake - both are extra dependencies.

Also see https://svnweb.freebsd.org/changeset/ports/285048
Post by Russell Haley
Please also note that I have made an upstream request to the Lua
community to consider applying a patch to the freebsd target in their
http://pastebin.com/cUCtWb1w. I don't expect this to happen quickly
however.
"freebsd" target is only slightly different from "linux" one. There's no
support to build shared library upstream, so -fPIC isn't required unless
you need to link liblua.a into another shared library.
Russell Haley
2016-07-22 20:27:50 UTC
Permalink
Sorry for the top post. Thank you for taking the time to clarify. 

Russ

Sent from my BlackBerry 10 smartphone on the Koodo network.
  Original Message  
From: Jan Beich
Sent: Friday, July 22, 2016 2:54 AM
To: Russell Haley
Cc: olli hauer; freebsd-***@freebsd.org
Subject: Re: Passing target to source Makefile
Post by Russell Haley
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
Post by Russell Haley
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.
Post by Russell Haley
4) The current Makefile applies -fPIC to some of the platforms, but
not armv6.
https://svnweb.freebsd.org/changeset/ports/409263
Post by Russell Haley
- Update to the latest Lua revision
Do you mean Mk/bsd.default-versions.mk? lang/lua53 is already at 5.3.3.
Post by Russell Haley
- Use clang and bmake instead of forcing gcc/gmake.
bmake isn't available on FreeBSD 9.3-RELEASE which isn't going to be
EOL'd until the next year. If you mean devel/bmake then I don't see the
benefit compared to devel/gmake - both are extra dependencies.

Also see https://svnweb.freebsd.org/changeset/ports/285048
Post by Russell Haley
Please also note that I have made an upstream request to the Lua
community to consider applying a patch to the freebsd target in their
http://pastebin.com/cUCtWb1w. I don't expect this to happen quickly
however.
"freebsd" target is only slightly different from "linux" one. There's no
support to build shared library upstream, so -fPIC isn't required unless
you need to link liblua.a into another shared library.
Russell Haley
2016-08-04 06:39:25 UTC
Permalink
Post by Jan Beich
Post by Russell Haley
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
Post by Russell Haley
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
http://www.freshports.org/search.php?query=arm-none-eabi&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive

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.

Thanks!
Russ

Loading...