On Sep 22, 2015, at 7:22 PM, René J.V. Bertin wrote:
> On Tuesday September 22 2015 18:39:13 Ryan Schmidt wrote:
>
>> That's correct. The compiler_blacklists_versions portgroup only knows how to
>> interpret the Apple-sepcific version numbers Apple assigns to its compilers
>> in Xcode. I didn't add version detection for compiler ports provided by
>> MacPorts because I thought it was unnecessary because we already know what
>> version they are.
>
> True, but what you don't know is what versions there are (or are going to be
> at some point in the future).
I don't see how that matters here.
>> But I just tried setting "compiler.whitelist macports-clang clang" in a
>> port. Then I used "port select clang mp-clang-3.4" and tried to configure
>> the port. It used /opt/local/bin/clang-mp-3.4. Then I used "port select
>> clang none" and cleaned and reconfigured the port. It used /usr/bin/clang.
>> So it looks like this might actually be ok: it would use the version of
>> MacPorts clang the user selected, if the user selected one, and Xcode clang
>> otherwise.
>
> Yes, that would be a solution, though it still means that building a port
> (successfully) can depend on having done a port select.
Not depend. Optionally use.
My understanding of your complaint is that you do not want MacPorts to install
MacPorts clang version A if the user already has MacPorts clang version B
installed and version B would also work. My proposal should partially address
that complaint, by allowing the user to use "port select clang" to indicate a
version of clang that they prefer. If a port blacklists all Xcode compilers and
needs to fall back to a MacPorts clang compiler, and the user's selected clang
compiler is compatible with the port, then it would be used. If not, MacPorts
would select (and install, if not already installed) a different MacPorts clang
compiler based on the existing fallback rules.
> There's also the question what happens when multiple ports whitelist
> macports-clang but have different requirements; you'd have to select the
> appropriate version manually and couldn't do a `upgrade outdated` when 2 or
> more of such ports are outdated. May not happen often, but it could.
Not relevant / not a problem. The port would indicate what versions of clang
are acceptable, via the normal compiler_blacklist_versions syntax. If the
user's selected version if not compatible, MacPorts will install and use a
different version of clang.
And let me state again that using compiler.whitelist is unusual. Usually you
should only use compiler.blacklist and perhaps compiler.fallback.
> My solution for Qt 5 on OS X 10.6 has been to create links to the target
> compiler in the port's install tree, and patch the Qmake configuration to use
> those links.
I don't understand why that would help anything. What programs are the links
pointing to, and why can't you tell Qmake's configuration to use those programs
directly?
> I've whipped up some attempts of my own which have a similar effect (but
> without the nice syntax). But to remain true to the reproducible build the
> simplest solution might be a function or variable that returns/contains
> either the latest version that's known to work on the host OS, or else the
> current latest stable release. That would be clang-3.4 on OS X <=10.6 without
> libc++; 3.5 with libc++, and 3.6 otherwise. That should cover most cases, as
> long as newer versions don't introduce severe regressions (and I suppose
> `clang` behaves the same way, in compiler.whitelist).
I don't think we need any function to return the latest stable version of clang
for an OS X version. If anything, we could improve the default value of
compiler.fallback in MacPorts base, so that it returns newer versions of clang
than 3.4 when libc++ is in use (assuming it's possible to determine that at
that point in the code).
> There's also the question whether the compiler should be recorded as build
> dependency of ports that impose a specific version.
MacPorts already does record the compiler port as a build dependency.
On Sep 22, 2015, at 7:24 PM, René J.V. Bertin wrote:
> On Tuesday September 22 2015 19:01:39 Ryan Schmidt wrote:
>
>> Well, I suppose the compiler_blacklist_versions portgroup could be smartened
>> to automatically add "macports-clang-3.4 macports-clang-3.3" if you specify
>> "{macports-clang < 3.5}".
>
> Is it me or does this look like there are multiple Ryans discussing among
> themselves here? :)
I try to craft my emails carefully, often proof-reading and rewriting them
several times before sending. Still, sometimes I realize after sending that
something I said could be improved, so I'll reply to myself.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
