On Sunday December 10 2017 18:38:44 Ryan Schmidt wrote:
> I'm not interested in continuing to debate what-ifs about the situation that
> at best won't change that fact.
Then again you're not the port maintainer and I never meant to bother you in
particular. Maybe I should have raised this on tr
On Dec 9, 2017, at 15:02, René J.V. Bertin wrote:
> On Saturday December 09 2017 11:35:07 Ryan Schmidt wrote:
>
>>> The main concern behind this thread was that building cmake would become
>>> impossible using a recent clang, esp. using clang 5+ with its new features
>>> that don't compile wit
On Saturday December 09 2017 11:36:14 Ryan Schmidt wrote:
>It should be used as a developer debugging tool. It should never be required
>for end users to install a port. If it is, it is a bug in the port's or its
>dependencies' compiler selection / blacklisting.
One thing that straightforward c
On Saturday December 09 2017 11:35:07 Ryan Schmidt wrote:
>> The main concern behind this thread was that building cmake would become
>> impossible using a recent clang, esp. using clang 5+ with its new features
>> that don't compile with older versions.
>
>Why is it necessary to attempt to buil
On Dec 9, 2017, at 11:31, Ken Cunninghamwrote:
>>
>> But come to think of it, if the commandline configure.compiler override is
>> not a glitch in my local install it also means that this concern is moot.
>>
>
>
> As an aside, I make extensive use of the command line configure.compiler
> ov
On Dec 9, 2017, at 11:26, René J.V. Bertin wrote:
> On Saturday December 09 2017 10:01:41 Ryan Schmidt wrote:
>
>> As far as I know, the port works as is, and it took a long time to get it
>> that way.
>
> What do you call long? I can easily imagine that the issues (on pre-10.9
> systems that
>
> But come to think of it, if the commandline configure.compiler override is
> not a glitch in my local install it also means that this concern is moot.
>
As an aside, I make extensive use of the command line configure.compiler
override and also the default_compiler setting in macports.conf
On Saturday December 09 2017 10:01:41 Ryan Schmidt wrote:
> As far as I know, the port works as is, and it took a long time to get it
> that way.
What do you call long? I can easily imagine that the issues (on pre-10.9
systems that don't use libc++ as the standard C++ runtime) commented on in t
On Dec 9, 2017, at 05:07, René J. V. Bertin wrote:
> René J.V. Bertin wrote:
>
>> This is not (directly) a dependency issue that affects the PortIndex so maybe
>> it's possible (and acceptable) to wrap the compiler.blacklist statement in a
>> test expression? I can figure out the former, the lat
René J.V. Bertin wrote:
> This is not (directly) a dependency issue that affects the PortIndex so maybe
> it's possible (and acceptable) to wrap the compiler.blacklist statement in a
> test expression? I can figure out the former, the latter a bit less ;-)
This seems to do the trick:
if {!([catc
Hi,
Looking at the latest port:cmake I see that it blacklists port:clang-3.8 and
higher via compiler.blacklist . I have the feeling that this shouldn't be
necessary except when you're going to install both the intended compiler and
cmake from scratch and from source.
- if you already have a pr
11 matches
Mail list logo
