How to enable trace mode automatically (to hide other ports while building)?

[Ryan Schmidt]

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.