On Sep 23, 2015, at 3:49 PM, René J.V. Bertin wrote:
> On Wednesday September 23 2015 15:35:38 Ryan Schmidt wrote:
>>
>> That sounds like a busted build system which should be fixed.
>
> It's only partly the fault of the build system; the rest is an interplay
> between compiler limitations and
On Wednesday September 23 2015 15:35:38 Ryan Schmidt wrote:
>
> That sounds like a busted build system which should be fixed.
It's only partly the fault of the build system; the rest is an interplay
between compiler limitations and code requirements.
> Sounds like the Qt build system sucks, an
On Sep 23, 2015, at 3:05 PM, René J.V. Bertin wrote:
> On Wednesday September 23 2015 14:07:25 Ryan Schmidt wrote:
>
>>> 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.
>
> Being able to us
On Wednesday September 23 2015 14:07:25 Ryan Schmidt wrote:
>> 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.
Being able to use a range expression means you don't have to keep coming back
to ada
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'
On Tuesday September 22 2015 19:01:39 Ryan Schmidt wrote:
>
> On Sep 22, 2015, at 6:39 PM, Ryan Schmidt wrote:
>
> > compiler.blacklist {clang < 600} {macports-clang < 3.5} macports-clang-3.4
> > macports-clang-3.3
> >
> > Apple and the clang project release versions at different times, so Appl
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
> MacP
On Sep 22, 2015, at 6:39 PM, Ryan Schmidt wrote:
> compiler.blacklist {clang < 600} {macports-clang < 3.5} macports-clang-3.4
> macports-clang-3.3
>
> Apple and the clang project release versions at different times, so Apple
> clang 600 might not correspond exactly to public clang 3.5. And not
On Sep 20, 2015, at 1:22 PM, René J.V. Bertin wrote:
> On Sunday September 20 2015 12:35:03 Ryan Schmidt wrote:
>
>> Range filtering is already included in the compiler_blacklist_versions
>> portgroup. An example is given in the portgroup:
>
> Yes,
>
>> # compiler.blacklist-append {clang >= 4
On Sep 20, 2015, at 1:21 PM, René J.V. Bertin wrote:
> On Sunday September 20 2015, Brandon Allbery wrote:
>
>> Because we can't provide any meaningful support if it's using a random
>> compiler?
>
> That's what I meant with discourage rather than disallow. Someone savvy
> enough to install a
On Sunday September 20 2015 12:35:03 Ryan Schmidt wrote:
>Range filtering is already included in the compiler_blacklist_versions
>portgroup. An example is given in the portgroup:
Yes,
># compiler.blacklist-append {clang >= 421.11.66 < 444}
That only applies to the Xcode clang versions, as far
On Sunday September 20 2015, Brandon Allbery wrote regarding "Re:
compiler.whitelist and compiler installation side-effects"
[this is a resurrected message]
>Because we can't provide any meaningful support if it's using a random
>compiler?
That's what I me
Let's keep the discussion on the mailing list.
On Sep 20, 2015, at 12:27 PM, René J.V. Bertin wrote:
> BTW, how difficult would it be to implement a range filter for blacklisting
> older macports-clang versions, or newer versions (3.7 doesn't build on OS X
> 10.6) :
>
> {macports-clang < 3.4}
On Sep 20, 2015, at 8:06 AM, René J. V. Bertin wrote:
> Ryan Schmidt wrote:
>
>> rule, that is the compiler that will be used. If Xcode does not provide
>> clang,
>> or if Xcode clang matches a blacklist rule (for example in your case, if
>> Xcode
>> clang is < build 500), then if macports-cla
On Sun, Sep 20, 2015 at 9:47 AM, René J.V. wrote:
> Is there any particular reason to disallow using Intel's compiler, rather
> than discourage it because of lack of testing? (or Xcode, if you take the
> above to the letter ^^)
Because we can't provide any meaningful support if it's using a ran
On Sunday September 20 2015, Brandon Allbery wrote regarding "Re:
compiler.whitelist and compiler installation side-effects"
>The point of the whitelist is to deal with buggy compilers. If 3.7 is
>preferred then it usually means that 3.6 can't build a working version of
&
On Sun, Sep 20, 2015 at 9:06 AM, René J. V. wrote:
> *) a white list is a list of acceptable items which is checked against
> what's
> available
>
The point of the whitelist is to deal with buggy compilers. If 3.7 is
preferred then it usually means that 3.6 can't build a working version of
the p
Ryan Schmidt wrote:
> rule, that is the compiler that will be used. If Xcode does not provide clang,
> or if Xcode clang matches a blacklist rule (for example in your case, if Xcode
> clang is < build 500), then if macports-clang-3.7 exists (which it does),
> macports-clang-3.7 will be used (being
On Sep 20, 2015, at 6:06 AM, René J.V. Bertin wrote:
> What are the exact effects in terms of compiler installation when I set?
>
>compiler.whitelistclang macports-clang-3.7 macports-clang-3.6
> macports-clang-3.5 macports-clang-3.4
> compiler.blacklist-append macports-llvm-gc
Hello,
What are the exact effects in terms of compiler installation when I set?
compiler.whitelistclang macports-clang-3.7 macports-clang-3.6
macports-clang-3.5 macports-clang-3.4
compiler.blacklist-append macports-llvm-gcc-4.2 llvm-gcc-4.2
compiler.blacklist-append g
20 matches
Mail list logo
