info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Passing target to source Makefile
10 views
Skip to first unread message
Russell Haley
Jul 21, 2016, 2:04:02 AM7/21/16
to
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
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
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
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Carsten Larsen
Jul 21, 2016, 2:26:31 PM7/21/16
to
Hi Russell,
> 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
> 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.
>
do-build:
${GMAKE} -C ${WRKSRC} TARGET=insert-here
Russell Haley
Jul 21, 2016, 3:25:33 PM7/21/16
to
On Thu, Jul 21, 2016 at 2:55 AM, olli hauer <oha...@gmx.de> wrote:
> On 2016-07-21 08:03, Russell Haley wrote:
>> Hi there,
>
> 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,
> On 2016-07-21 08:03, Russell Haley wrote:
>> 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.
>>
>> 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,
>> because the lua makefile is defaulting to install the files (due to
>> the lack of target) and overriding the makeplist output?
>>
>> Thanks,
>>
>> Russell
>
>
> 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 Haley
Jul 21, 2016, 5:07:01 PM7/21/16
to
On Thu, Jul 21, 2016 at 2:55 AM, olli hauer <oha...@gmx.de> wrote:
> On 2016-07-21 08:03, Russell Haley wrote:
>> 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
> On 2016-07-21 08:03, Russell Haley wrote:
>> 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
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
Jul 22, 2016, 2:59:21 AM7/22/16
to
On 21/07/2016 20:25, Russell Haley wrote:
> 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
> 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.
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
Jul 22, 2016, 4:54:47 AM7/22/16
to
Russell Haley <russ....@gmail.com> 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
> 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.
"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.
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.
> 4) The current Makefile applies -fPIC to some of the platforms, but
> not armv6.
> - Update to the latest Lua revision
> - Use clang and bmake instead of forcing gcc/gmake.
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
> 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.
support to build shared library upstream, so -fPIC isn't required unless
you need to link liblua.a into another shared library.
Russell Haley
Jul 22, 2016, 4:28:09 PM7/22/16
to
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; freebs...@freebsd.org
Subject: Re: Passing target to source Makefile
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; freebs...@freebsd.org
Subject: Re: Passing target to source Makefile
Russell Haley
Aug 4, 2016, 2:39:41 AM8/4/16
to
On Fri, Jul 22, 2016 at 1:53 AM, Jan Beich <jbe...@vfemail.net> wrote:
> Russell Haley <russ....@gmail.com> 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
> Russell Haley <russ....@gmail.com> 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.
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
0 new messages