On Oct 3, 2014, at 5:04 PM, Ryan Schmidt wrote:
> Any ports that clear those variables should no longer do so. Instead they
> should "-delete" from them those values that they don't want there, for
> example "configure.ldflags-delete -L${prefix}/lib". This process could
> already be begun now.
On Oct 4, 2014, at 3:47 AM, Joshua Root wrote:
>
> On 2014-10-4 11:09 , Ryan Schmidt wrote:
>>
>> On Oct 3, 2014, at 4:47 PM, Joshua Root wrote:
>>>
>>> On 2014-10-4 07:04 , Ryan Schmidt wrote:
"-arch" flags may or may not be doable. Joshua previously thought this was
not fixab
On 2014-10-4 11:09 , Ryan Schmidt wrote:
>
> On Oct 3, 2014, at 4:47 PM, Joshua Root wrote:
>>
>> On 2014-10-4 07:04 , Ryan Schmidt wrote:
>>>
>>> "-arch" flags may or may not be doable. Joshua previously thought this was
>>> not fixable.
>>
>> Depends what you mean by "this" and "fixable". Cert
On Oct 3, 2014, at 4:47 PM, Joshua Root wrote:
>
> On 2014-10-4 07:04 , Ryan Schmidt wrote:
>>
>> "-arch" flags may or may not be doable. Joshua previously thought this was
>> not fixable.
>
> Depends what you mean by "this" and "fixable". Certainly it's impossible
> for any variable that can
On 2014-10-4 07:04 , Ryan Schmidt wrote:
>
> "-arch" flags may or may not be doable. Joshua previously thought this was
> not fixable.
Depends what you mean by "this" and "fixable". Certainly it's impossible
for any variable that can be read at any point to always reflect the
existence of a var
> On Oct 3, 2014, at 11:44 AM, Sean Farley wrote:
>
>
> Ryan Schmidt writes:
>
>> On Oct 2, 2014, at 4:24 PM, Sean Farley wrote:
>>>
>>> The petsc port, in an attempt to help users, ignores CFLAGS (and
>>> friends) from the environment due to many users that accidentally had
>>> them defined.
Ryan Schmidt writes:
> On Oct 2, 2014, at 4:24 PM, Sean Farley wrote:
>>
>> The petsc port, in an attempt to help users, ignores CFLAGS (and
>> friends) from the environment due to many users that accidentally had
>> them defined. So, I'm trying to pass the exact same CFLAGS to
>> configure.args
On Oct 2, 2014, at 4:24 PM, Sean Farley wrote:
>
> The petsc port, in an attempt to help users, ignores CFLAGS (and
> friends) from the environment due to many users that accidentally had
> them defined. So, I'm trying to pass the exact same CFLAGS to
> configure.args.
I see their configure scrip
On Oct 2, 2014, at 6:13 PM, Ryan Schmidt wrote:
> On Oct 2, 2014, at 4:29 PM, Lawrence Velázquez wrote:
>
>> For my part, when I implemented configure.cxx_stdlib, I was primarily
>> thinking about preventing Portfiles from trashing the "-stdlib" argument.
>> Augmenting configure.cxxflags seeme
You could alternately try to patch the code to pay attention to CFLAGS. I'm
not sure how complicated that would be in the build system.
David
On Thu, Oct 2, 2014 at 6:13 PM, Ryan Schmidt
wrote:
>
> On Oct 2, 2014, at 4:29 PM, Lawrence Velázquez wrote:
> >
> > On Oct 2, 2014, at 5:13 PM, Ryan Sc
On Oct 2, 2014, at 4:29 PM, Lawrence Velázquez wrote:
>
> On Oct 2, 2014, at 5:13 PM, Ryan Schmidt wrote:
>
>> On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:
>>
>>> I suspect the idea is to prevent ports from clearing CFLAGS and such.
>>
>> I think it's more that in many cases -- arch f
On Oct 2, 2014, at 5:13 PM, Ryan Schmidt wrote:
> On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:
>
>> I suspect the idea is to prevent ports from clearing CFLAGS and such.
>
> I think it's more that in many cases -- arch flags for example, or which C++
> stdlib flag to use -- MacPorts w
Ryan Schmidt writes:
> On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:
>
>> On Oct 2, 2014, at 5:08 PM, Sean Farley wrote:
>>
>>> Ryan Schmidt writes:
>>>
Unfortunately as far as I can tell the answer is no. Many variables are
added to ${configure.cflags} right before the comma
On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:
> On Oct 2, 2014, at 5:08 PM, Sean Farley wrote:
>
>> Ryan Schmidt writes:
>>
>>> Unfortunately as far as I can tell the answer is no. Many variables are
>>> added to ${configure.cflags} right before the command is run and after the
>>> po
On Oct 2, 2014, at 5:08 PM, Sean Farley wrote:
> Ryan Schmidt writes:
>
>> Unfortunately as far as I can tell the answer is no. Many variables are
>> added to ${configure.cflags} right before the command is run and after the
>> port has any opportunity to intercept it or learn about it.
>
> T
Ryan Schmidt writes:
> On Oct 2, 2014, at 3:25 PM, Sean Farley wrote:
>
>> This seems very odd but is there a variable that stores the complete
>> string of what will eventually be CFLAGS in the environment
>> (e.g. CFLAGS=foo ./configure --args) passed to a command?
>>
>> If you're like me, you
On Oct 2, 2014, at 3:25 PM, Sean Farley wrote:
> This seems very odd but is there a variable that stores the complete
> string of what will eventually be CFLAGS in the environment
> (e.g. CFLAGS=foo ./configure --args) passed to a command?
>
> If you're like me, you're thinking: "Of course there
This seems very odd but is there a variable that stores the complete
string of what will eventually be CFLAGS in the environment
(e.g. CFLAGS=foo ./configure --args) passed to a command?
If you're like me, you're thinking: "Of course there is, use
configure.cflags!" But that only holds a substring
18 matches
Mail list logo
