On Mar 27, 2018, at 06:41, Mojca Miklavec wrote:
> On 27 March 2018 at 08:31, Ryan Schmidt wrote:
>>
>>> On Mar 26, 2018, at 01:25, Mojca Miklavec wrote:
>>>> On 26 March 2018 at 02:49, Ryan Schmidt wrote:
>>>>> On Mar 25, 2018, at 14:37, David B. Evans wrote:
>>>>>
>>>>>> +# blacklist compilers that do not support C11 (redefinition of typedef
>>>>>> ‘GtkSourceTag’ at gtksourceview/gtksourcetag.h:35)
>>>>>> +compiler.blacklist *gcc* {clang < 300}
>>>>>
>>>>> Please be more specific here, such as "*gcc-3.* *gcc-4.*". Newer versions
>>>>> of gcc do support C11, and a change was already committed to MacPorts
>>>>> base which will let PowerPC systems fall back to gcc6 instead of clang
>>>>> (since clang doesn't work on PowerPC). Other ports may need more-specific
>>>>> blacklists too.
>>>>
>>>> Is there any chance to implement something like
>>>> compiler.blacklist {gcc < 4.7} {macports-clang < 3.7}
>>>> ?
>>
>> There is no code currently written that would allow that to work. If we were
>> to add code to the compilers_blacklist_versions for that, how should it work?
>
> I don't know how the current implementation works, but from the
> functional point of view ...
>
>> Currently, the above line would mean "blacklist versions of the compiler
>> named 'gcc' that are earlier than 4.7" and "blacklist versions of the
>> compiler named 'macports-clang' that are earlier than 3.7". There are no
>> compilers in MacPorts named "gcc" or "macports-clang" so these statements
>> would currently have no effect. Are you proposing that the names "gcc" and
>> "macports-clang" be special-cased in the portgroup, and taken to mean "the
>> set of ports whose names start with 'gcc'" (or maybe even "...whose names
>> contain 'gcc'"?) and "the set of ports whose names start with
>> 'macports-clang'"? That's a plausible solution, I'm just pointing out that
>> it would be special-case code.
>
> Yes, that's the meaning that I would like to convey through that syntax.
I can understand that. But I just want to make sure you understand that's not
at all what the portgroup currently does.
Currently, it examines each item of compiler.blacklist. If the item is a single
word, such as *gcc-4.*, it is skipped; MacPorts base will do the actual
blacklisting of that compiler later. If the item has more than one word, such
as {clang < 500} (3 words), it takes the first word (in this example "clang")
as the MacPorts compiler name. It asks MacPorts what the executable name is for
that compiler name, then it runs that executable with the "-v" flag, which
causes the compiler to print its version number and other information. For each
compiler the portgroup knows about (clang, apple-gcc-4.2, llvm-gcc-4.2,
gcc-4.2, gcc-4.0), it knows how to extract the version number and build number
from the "-v" output using a regular expression. Then, until there are no more
words in this compiler blacklist value, it gets the next two words (in this
example "< 500") and performs that numeric comparison against the compiler's
actual version. If it matches, then the compiler is to be blacklisted, and the
compiler name by itself ("clang") is added to compiler.blacklist, so that
MacPorts base will blacklist it.
> The list for {gcc < 4.7} should cover (using
> https://trac.macports.org/wiki/UsingTheRightCompiler as reference):
> - apple-gcc-4.[02]
> - gcc-3.3
> - gcc-4.[02]
> - llvm-gcc-4.2
> - macports-gcc-4.[3456]
> - macports-llvm-gcc-4.2
> - macports-dragonegg-3.[45]-gcc-4.[56]
>
> List of problematic compilers which should probably always be blacklisted :)
> - cc
> - gcc (/usr/bin/gcc)
> - macports-gcc
"Always blacklisted" makes no sense. If those compiler should never be used,
they should not be in the fallback list in the first place. You can check
portconfigure.tcl to see if they're in the list, and if so, you can discover
why by looking at the blame output.
> For macports-clang I would have suggested using {clang < 3.7}, but
> that one has already been taken :)
There is another proposal which is that when we blacklist Xcode clang using
e.g. {clang < 500}, then the portgroup should automatically add to the list the
MacPorts clang version(s) that correspond to that Xcode clang blacklist. The
only problem with that proposal is that we don't have a list that correlates
those versions numbers.
https://trac.macports.org/ticket/56093
