base: find a method to move portconfigure.tcl into the ports tree so it can be hotfixed between releases.

[kencu (Ken)]

There are always a few issues that come up with base as time goes by -- currently we have tweaks regarding thread_local, c++11 selection on older systems, c++14 compiler selection, C11 compiler selection tweaks, and also c++17 compiler selection tweaks.

All these are added to various ports with comments to remove them once base is updated.

This seems pretty inefficient, and I suspect more of this will go on with the new added architecture and the inevitable issues coming forth from that.

It would be more agile if portconfigure.tcl could be moved into the ports tree for hotfixing, and a lot of this work could be done at one time, in one place, as the issues are found.

[ryandesign (Ryan Carsten Schmidt)]

While it would not be appropriate to move the whole of portconfigure.tcl into the ports tree, the compiler selection logic could be. We already moved some similar functionality from base to the ports tree. See for example browser:macports-ports/_resources/port1.0/compilers and browser:macports-ports/_resources/macports1.0/xcode_versions.ini​.

[ryandesign (Ryan Carsten Schmidt)]

Note that I'm not saying that we should do this, just saying that it should be possible.

I agree with you that there are bugs in the MacPorts 2.6.2 compiler selection logic. I am not yet convinced that these will happen so often that your proposal is necessary. The compiler selection logic was overhauled in MacPorts 2.6.0 including adding the c_standard and cxx_standard and thread_local_storage options. The changeset was so large that it was difficult to review. It is not surprising that a few bugs crept in, but note that they are bugs in features we never had before. They've been or are being fixed in master and there will be a new release of base.

[kencu (Ken)]

I have actually wondered why _all_ the tcl logic in MacPorts port1.0 should not be moved into the ports tree, to be honest, but 20 years into it, I presume there must have been some reason that is not immediately obvious to me.

But the compiler selection part is certainly the most fluid, and low-hanging fruit.

[kencu (Ken)]

another benefit might be that it would probably allow us to start clearing out the insane number of PortGroups, which seem to multiply every long weekend.

[jmroot (Joshua Root)]

There's no requirement to have a copy of the official ports tree to use MacPorts.

[ryandesign (Ryan Carsten Schmidt)]

Yes we have too many portgroups and many of them should probably be implemented in base instead. But many portfile authors, myself included, find it easier to write portgroup than figure out where in base things should go, so portgroups proliferate.

[kencu (Ken)]

Replying to jmroot:

There's no requirement to have a copy of the official ports tree to use MacPorts.

Yes, I suppose if that use case is felt to be a requirement, then moving some of the functionality into the ports tree would not work.

Or perhaps it would be better to require that the official macports ports tree be available to install ports, as that must represent 99.995% of users. Then that would no longer be an issue.

[kencu (Ken)]

Replying to ryandesign:

Yes we have too many portgroups and many of them should probably be implemented in base instead.

I don't think we should underestimate how much the nebulous and prolific portgroups make it difficult for new users to contribute.

Four years in, I will not touch the compilers portgroup. What the hell does it do? I'm afraid of it.

[kencu (Ken)]

i will learn to stop making suggestions eventually.