On Jan 10, 2013, at 23:52, ni...@macports.org wrote:
> Revision: 101455
> https://trac.macports.org/changeset/101455
> Author: ni...@macports.org
> Date: 2013-01-10 21:52:00 -0800 (Thu, 10 Jan 2013)
> Log Message:
> ---
> kde4-runtime: correct typo in preprocessor
>
> Modi
On Jan 10, 2013, at 21:59, Ryan Stonecipher wrote:
> Ryan Schmidt wrote:
>
>> There are other nuances of unified ports. The best documentation is to read
>> existing ports using the portgroup—there are tons of them.
>
> Many ports written in the differing styles of several maintainers are not
> Date: Thu, 10 Jan 2013 12:21:56 -0600
> From: Ryan Schmidt
> Subject: Re: Unified Python portgroup
>
> There are other nuances of unified ports. The best documentation is to
> read existing ports using the portgroup?there are tons of them.
Many ports written in the differing styles of several
On Thu, Jan 10, 2013 at 8:53 PM, Ryan Schmidt wrote:
> I'm looking through them but not really finding the example I was hoping for.
> A lot of Jeremy Huddleston's ports do this:
>
> configure.compiler gcc-4.2
> if {![file exists ${configure.cc}]} {
> depends_build-append port:apple-gcc42
>
On Jan 10, 2013, at 6:53 PM, Ryan Schmidt wrote:
>
> On Jan 10, 2013, at 20:40, Adam Mercer wrote:
>
>> On Thu, Jan 10, 2013 at 8:22 PM, Ryan Schmidt wrote:
>>
+# build fails with gcc-4.0 on Leopard, use gcc-4.2 (#37069)
+if {${configure.compiler} == "gcc-4.0"} {
+ configure.
On Jan 10, 2013, at 20:40, Adam Mercer wrote:
> On Thu, Jan 10, 2013 at 8:22 PM, Ryan Schmidt wrote:
>
>>> +# build fails with gcc-4.0 on Leopard, use gcc-4.2 (#37069)
>>> +if {${configure.compiler} == "gcc-4.0"} {
>>> + configure.compiler gcc-4.2
>>> +}
>>
>> Couldn't this just be written as
On Thu, Jan 10, 2013 at 8:22 PM, Ryan Schmidt wrote:
Ryan
>> +# build fails with gcc-4.0 on Leopard, use gcc-4.2 (#37069)
>> +if {${configure.compiler} == "gcc-4.0"} {
>> + configure.compiler gcc-4.2
>> +}
>
> Couldn't this just be written as:
>
> compiler.blacklist gcc-4.0
>
> Of course this
On Jan 8, 2013, at 20:43, r...@macports.org wrote:
> Revision: 101344
> https://trac.macports.org/changeset/101344
> Author: r...@macports.org
> Date: 2013-01-08 18:43:39 -0800 (Tue, 08 Jan 2013)
> Log Message:
> ---
> python/py-matplotlib: build fails with gcc-4.0 on Leopa
On Jan 10, 2013, at 08:23, Rainer Müller wrote:
> I tried to use the perl5 port group to create a port for an application,
> not a module. The port group insists on using the version of perl
> extracted from the currently installed ${prefix}/bin/perl. Actually this
> is the renaming of p5-app-ack
On Jan 10, 2013, at 16:51, Freek Dijkstra wrote:
> On 10-01-2013 15:25, Jeremy Lavergne wrote:
>
>> You need:
>> sudo port -d install subport=py27-pdfrw
>
> Thanks Jeremy,
>
> Your answer is spot-on. With this syntax, the modified Portgroup behaved
> as it should.
>
> I never made the mental
On Jan 10, 2013, at 16:47, ebori...@macports.org wrote:
> Revision: 101428
> https://trac.macports.org/changeset/101428
> Author: ebori...@macports.org
> Date: 2013-01-10 14:47:25 -0800 (Thu, 10 Jan 2013)
> Log Message:
> ---
> py-spyder-beta: Resurrect to track 2.2 develop
On 11-01-2013 00:06, Jeremy Lavergne wrote:
> When building portindex, the unnamed versions aren't created so users won't
> ever stumble upon them.
Ah, thanks again. I now (slowly) start to understand how subports work.
Freek
___
macports-dev mailing
>>> [...] "python.versions 25 26 27". To my surprise the
>>> following command was accepted:
>>>
[root@lampje] Code/macports/py-pdfrw# port install subport=py32-pdfrw
---> Computing dependencies for py32-pdfrw
> [...]
---> Configuring py32-pdfrw
---> Building py32-pdfrw
On 10-01-2013 23:57, Jeremy Lavergne wrote:
>> [...] "python.versions 25 26 27". To my surprise the
>> following command was accepted:
>>
>>> [root@lampje] Code/macports/py-pdfrw# port install subport=py32-pdfrw
>>> ---> Computing dependencies for py32-pdfrw
[...]
>>> ---> Configuring py32-pdfrw
On 10-01-2013 15:25, Jeremy Lavergne wrote:
> You need:
> sudo port -d install subport=py27-pdfrw
Thanks Jeremy,
Your answer is spot-on. With this syntax, the modified Portgroup behaved
as it should.
I never made the mental link between "Unified portgroup" and "subport"
otherwise I would have p
On Jan 10, 2013, at 1:19 PM, Ryan Schmidt
wrote:
> you should not be blacklisting clang based on Xcode or OS version, but based
> on clang version. Please use the compiler_blacklist_versions portgroup for
> this.
OK; so I added:
{{{
PortGroup compiler_blacklist_versions 1.0
}}}
and
> libnet11: fix fix autoreconf failure with automake 1.13
Now with extra fix scent.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
On Jan 10, 2013, at 08:25, Jeremy Lavergne wrote:
>> That is actually not a bug! You're trying to install it directly from the
>> directory, which is equivalent to running `port -d install py-pdfrw`. Now,
>> since you didn't provide a py24-* subport, the behaviour defined in the
>> python port
On Jan 10, 2013, at 07:30, Michael Dickens wrote:
> The primary symptom is that LIBRARY_PATH is not being honored. Which is
> why the comment in the qt4-mac Portfile about qt4 (really, the port
> qt4-mac) not compiling with clang 3.0 or older. The "feature" was not
> corrected until at least th
On 01/10/2013 07:28 AM, Joshua Root wrote:
On 2013-1-9 16:12 , Blair Zajac wrote:
On 1/8/13 8:51 PM, Blair Zajac wrote:
On 1/5/13 2:46 PM, Blair Zajac wrote:
A 1_3.2.0_0 style version number won't work with Apple's version
number, which
can only accept digits, so I do the following:
v = "
On 1/10/13 8:23 AM, Rainer Müller wrote:
> I tried to use the perl5 port group to create a port for an application,
> not a module. The port group insists on using the version of perl
> extracted from the currently installed ${prefix}/bin/perl.
This seems like the right thing to do IMO. ${prefix}
On 2013-01-10 16:21, Michael Schout wrote:
> On 1/10/13 8:23 AM, Rainer Müller wrote:
>
>> I tried to use the perl5 port group to create a port for an application,
>> not a module. The port group insists on using the version of perl
>> extracted from the currently installed ${prefix}/bin/perl.
>
On 2013-1-9 16:12 , Blair Zajac wrote:
> On 1/8/13 8:51 PM, Blair Zajac wrote:
>> On 1/5/13 2:46 PM, Blair Zajac wrote:
>>> A 1_3.2.0_0 style version number won't work with Apple's version
>>> number, which
>>> can only accept digits, so I do the following:
>>>
>>>v = "${epoch}.${version}.${rev
> That is actually not a bug! You're trying to install it directly from the
> directory, which is equivalent to running `port -d install py-pdfrw`. Now,
> since you didn't provide a py24-* subport, the behaviour defined in the
> python portgroup for running install without specifying a version (
On 10/gen/2013, at 09:57, Freek Dijkstra wrote:
> Hi all,
>
> Is there any documentation for the unified Python portgroup? The guide
> does not yet mention it, and searching the mailing list only resulted in
> one thread.
I don't think there's a guide other than peering through the portgroup, l
Hello,
I tried to use the perl5 port group to create a port for an application,
not a module. The port group insists on using the version of perl
extracted from the currently installed ${prefix}/bin/perl. Actually this
is the renaming of p5-app-ack, #37595 [1].
nameack
perl5.b
> On Jan 9, 2013, at 11:33 PM, Ryan Schmidt wrote:
> > On Jan 9, 2013, at 19:38, michae...@macports.org wrote:
> > # Qt4 does not compile with clang 3.0 or older; it also does not work
> > -# with Apple's clang from XCode 4.4 or older. Block the clang
> > -# versions, both from Apple and MacPorts
Hi all,
Is there any documentation for the unified Python portgroup? The guide
does not yet mention it, and searching the mailing list only resulted in
one thread.
I submitted a Portfile for py27-pdfrw, and was asked to modify it to use
the unified python 1.0 portgroup. I'm happy to do so, but wh
28 matches
Mail list logo
