[105866] trunk/dports/python/py-graph-tool/Portfile

[Mark Moll]

On May 8, 2013, at 2:12 PM, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> On May 8, 2013, at 12:47, mmoll at macports.org wrote:
> 
>> Revision: 105866
>>         https://trac.macports.org/changeset/105866
>> Author:   mmoll at macports.org
>> Date:     2013-05-08 10:47:21 -0700 (Wed, 08 May 2013)
>> Log Message:
>> -----------
>> py-graph-tool: update to version 2.2.24
>> 
>> Modified Paths:
>> --------------
>>   trunk/dports/python/py-graph-tool/Portfile
>> 
>> Modified: trunk/dports/python/py-graph-tool/Portfile
>> ===================================================================
>> --- trunk/dports/python/py-graph-tool/Portfile	2013-05-08 17:39:06 UTC (rev 105865)
>> +++ trunk/dports/python/py-graph-tool/Portfile	2013-05-08 17:47:21 UTC (rev 105866)
>> @@ -7,7 +7,7 @@
>> 
>> set realname        graph-tool
>> name                py-${realname}
>> -version             2.2.23
>> +version             2.2.24
>> categories          python science
>> platforms           darwin
>> license             GPL-3
>> @@ -20,9 +20,9 @@
>> homepage            http://graph-tool.skewed.de
>> master_sites        http://downloads.skewed.de/graph-tool/
>> use_bzip2           yes
>> -checksums           md5     d4d7da6a906f458baf3b2c01e86b76e2 \
>> -                    sha1    3924f10ae7507392f9b5fc38e18b299e4f2fcb9d \
>> -                    rmd160  ffd845d9da3c8708804c60a6d0c7f5732980be1b
>> +checksums           md5     1c1ec9e8df33fe1d1560736b98816743 \
>> +                    sha1    0ba18967a749396c8a959e423cb6c9532add4432 \
>> +                    rmd160  cc1979e17e4604b163bc2a620c4c76b9c4ff58d6
>> distname            ${realname}-${version}
>> python.versions     26 27 31 32
>> python.default_version 27
>> @@ -40,6 +40,8 @@
>>                       port:py${python.version}-gobject3 \
>>                       port:py${python.version}-cairo
>>    use_configure      yes
>> +    # parallel build starts swapping, even on a MacBook Pro with 8GB of RAM.
>> +    use_parallel_build no
> 
> Is this because of clang, which tends to use more RAM than other compilers? If so, you could leave parallel building on when configure.compiler does not match "*clang*".


Could be. It uses very heavily-templated code, so I wouldn’t be surprised if it was a problem for gccXX as well. I don’t have an easy way to test it, since I think I’d have to recompile boost with gccXX as well.

-- 
Mark Moll