Chris Johns wrote:
Will Coleda wrote:
I /think/ there is a mechanism
to allow specifying a config file to be used instead of using the one
Configure.pl would build after probing your system.
perldoc Configure.pl
... then search for: Configuration-File Interface
... This was a feature that J
On Tue, 9 Feb 2010, Will Coleda wrote:
> Ok. I've started down this path in the rm_cflags branch - it already
> has removed the perl script; I'd appreciate some tests on something
> other than gcc/gmake. I broke out the 2 files that added flags and
> those are done, and dropped several cases from
Will Coleda wrote:
On Mon, Feb 8, 2010 at 7:46 PM, Chris Johns wrote:
On 2/9/2010 9:01 AM, Joel Sherrill wrote:
On 02/08/2010 12:57 PM, Andrew Whitworth wrote:
I'm pretty strongly in favor of this change. Having more information
available about how individual files are compiled is always a go
Hi!
On Tue, Feb 9, 2010 at 1:35 PM, Jonathan Leto wrote:
> Howdy,
>
>> While Columbus might be great for co-location with Yapc, we might benefit
>> from a different place if a large fraction of the group won't be yapcing.
>>
>> =Austin
>
> I am going to throw out that I am helping organize the Ha
On Tue, Feb 9, 2010 at 4:24 PM, Jonathan Leto wrote:
> Howdy,
>
>>> If Parrot builds tools on the host require to build the target code there
>>> needs to be 2 separate sets of flags. Does it ? Typically HOST_CFLAGS
>>> handles the host and CFLAGS handles the target. This also goes for CC where
>>
Howdy,
> While Columbus might be great for co-location with Yapc, we might benefit
> from a different place if a large fraction of the group won't be yapcing.
>
> =Austin
I am going to throw out that I am helping organize the Hacker Lounge
at the Open Source Bridge 2010 conference [0], so I would
Howdy,
>> If Parrot builds tools on the host require to build the target code there
>> needs to be 2 separate sets of flags. Does it ? Typically HOST_CFLAGS
>> handles the host and CFLAGS handles the target. This also goes for CC where
>> HOST_CC handles the host compiler and CC is the target comp
On 02/09/2010 07:32 AM, Will Coleda wrote:
On Mon, Feb 8, 2010 at 7:46 PM, Chris Johns wrote:
On 2/9/2010 9:01 AM, Joel Sherrill wrote:
On 02/08/2010 12:57 PM, Andrew Whitworth wrote:
I'm pretty strongly in favor of this change. Having more information
available about how in
On Tuesday 09 February 2010 at 07:24, coke wrote:
> Log:
> Eliminate some unused variables and static functions.
>
> Most interesting one is the string creation inside the loops in
src/call/args.c
> - might be worth a benchmark on trunk.
> @@ -823,7 +822,6 @@
> GETATTR_FixedIntegerArray_i
2010/2/9 Vasily Chekalkin :
> Hello.
>
> Branch is ready for _extensive_ testing. Especially with HLLs.
>
this branch 'gc_encapsulate_part2' works like the trunk on Windows/mingw,
see http://smolder.plusthree.com/app/projects/report_details/32125
François
> Main purpose of branch: encapsulate al
Hello.
Branch is ready for _extensive_ testing. Especially with HLLs.
Main purpose of branch: encapsulate all access to interp->mem_pools
inside gc_ms.
Some statistic:
ba...@icering:~/src/parrot$ ack -clQ 'interp->mem' src
src/gc/gc_ms.c:63
Branch probably introduced some slowing down due i
On Mon, Feb 8, 2010 at 7:46 PM, Chris Johns wrote:
>
> On 2/9/2010 9:01 AM, Joel Sherrill wrote:
>>
>> On 02/08/2010 12:57 PM, Andrew Whitworth wrote:
>>>
>>> I'm pretty strongly in favor of this change. Having more information
>>> available about how individual files are compiled is always a good
On Mon, Feb 8, 2010 at 8:03 PM, Andy Dougherty wrote:
> On Mon, 8 Feb 2010, Will Coleda wrote:
>
>> My question is: is it necessary for us to jump through these hoops?
>> Most of the directives in CFLAGS.in are to quiet a noisy build. The
>> most complicated turn off optimization in some or all ca
13 matches
Mail list logo
