On Sep 20, 2015, at 1:46 PM, Mojca Miklavec wrote:
> On Fri, Sep 18, 2015 at 12:08 PM, Ryan Schmidt wrote:
>
>> For this particular problem, the correct solution is to fix the lua port by
>> renaming it to lua53 and making it install its headers to a directory that
>> is not ${prefix}/include (and its libraries to a location that is not
>> ${prefix}/lib), just like the other lua ports already do.
>
> As someone pointed out, we might then just as well end up with
> lua5x-modulename
> "mess" for the lua modules
A lot of effort was put into providing multiple simultaneously installable
versions of other languages and their modules. I don't consider that a mess; I
consider it a feature. I spent a lot of time making the php port and portgroup
work this way and am very proud of it and pleased with the way it works. I'm
sure Josh spent a lot time on the python portgroup and ports and they work well
too. I realize there have been complaints about the perl portgroup and ports,
but that's a unique situation, due to the large number of perl versions that
have been released in recent years, the large number of perl modules that we
have in MacPorts, and the feeling that perl is pretty good at maintaining
backward compatibility such that just having the current version might be good
enough, and a good deal simpler. But I don't think that would do for lua which
isn't so good at backward compatibility.
There's a game engine I've been interested for a few years in adding to
MacPorts. That engine is based on lua, and it too isn't good at backward
compatibility: games written for one version of the engine may need drastic
changes to work with later versions of the engine. Since these are probably
small games written by a single developer who has since moved on to other
projects, it's likely that they haven't updated their game to work with the
latest version of the engine. So since my goal is to add some of these games to
MacPorts, a prerequisite is to add ports for various versions of the engine,
and a prerequisite for that is having ports for various versions of lua. I
don't know if it requires any other lua modules, but it makes sense that if you
can install different versions of lua, you should be able to install the
available modules for any of those versions too.
> and we will lose the ability to use lua
> "out-of-the-box" for programs outside of macports.
"port select lua" should address that issue.
> I'm not sure if and
> how many lua modules we currently ship though.
I see only 21 ports whose names begin with "lua-", so a very small number at
this point.
> I'm not strictly
> against that change, but it needs some thought. (I'm also seriously
> considering downgrading the lua port back to version 5.2.)
>
> I kind of keep hoping that the number of programs that are
> incompatible with lua 5.3 (and/or 5.2) will keep decreasing and
> hopefully drop to zero at some point. I know luajit won't though.
Yes but lua is a language, used not only by MacPorts ports but also directly by
users, which is why languages are one of the types of ports that we typically
offer in multiple versions. A user might conceivably want to run lua code that
requires a particular lua version -- even after we've updated the ports in
MacPorts to use newer versions of lua.
> I remember talking about switching the trace mode on by default and
> some people having doubts about the change. But given that all the
> tricky work has been done already, I could imagine that making some
> option inside a port should be doable without too much work.
Possibly. In years past, MacPorts made universal builds and parallel builds
enabled by default, and provided a way for individual ports to disable those
features. Before parallel building was on by default, ports could opt into it.
We may possibly want to similarly allow ports to opt in or out of trace mode.
> A particular port that I was trying to upgrade (SciTE) has a build
> conflict with a completely unrelated port which just happens to have a
> header file with the same name (and different casing).
Yup, that's what conflicts_build is for.
> Hiding
> non-dependent ports would solve many such problems.
Yup.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
