On Jul 25, 2013, at 2:07 AM, jerem...@macports.org wrote:
> Revision: 108512
> https://trac.macports.org/changeset/108512
> Author: jerem...@macports.org
> Date: 2013-07-24 23:07:28 -0700 (Wed, 24 Jul 2013)
> Log Message:
> ---
> Remove compiler dependency hacks now that use
On 2013-7-25 05:56 , Daniel J. Luke wrote:
> Is there a way (planned?) for a port to be able to supply a (list of) path(s)
> to add to the sandbox?
Planned, but...
> for the subversion-javahlbindings port, we put a symlink into
> /Library/Java/Extensions
That should be allowed provided you cor
dstru...@gmail.com writes:
>> Ah, that's something I tried to do at first as well. It's not possible
>> since it would lead to non-unique builds. For example, let's assume
>> arpack has a known problem with gcc46 and an unknown bug with
>> gcc45. In the arpack portfile, we'll put an error if +mpi
On Wed, Jul 24, 2013 at 03:56:19PM -0400, Daniel J. Luke wrote:
> Is there a way (planned?) for a port to be able to supply a (list of)
> path(s) to add to the sandbox?
There is an option portsandbox_profile [1], which is set in proc
target_run in portutil.tcl, line 1323 [2] by calling
portsandbox
> > I think in most cases that if you use MPI, then there is no need to
> specify
> > the underlying compiler also (since compiling even non-MPI code in the
> > package with mpich +gfortran is the same as just using gfortran).
> Recently,
> > we sorted this out for the arpack port.
>
> Ah, that's s
Is there a way (planned?) for a port to be able to supply a (list of) path(s)
to add to the sandbox?
for the subversion-javahlbindings port, we put a symlink into
/Library/Java/Extensions
For now, I set 'portsandbox_active no' in the Portfile, but I'd really rather
let it run with the sandbox
ryandes...@macports.org writes:
> On Jul 24, 2013, at 13:55, Sean Farley wrote:
>
>> If the port wants to do something specialized then it could simply put
>> the special code in an if-block:
>>
>> if {[variant_isset gcc46]} {
>> ...
>> }
>
> That's true…
>
>
>>> Setting compiler.blacklist as n
dstru...@mit.edu writes:
> On Sat, Jul 20, 2013 at 7:28 PM, Sean Farley wrote:
>
>> Hi all,
>>
>> I'm looking for comments and feedback for two new port groups:
>> multiple compilers [1] and mpi [2]. My goal is to unify all the gcc4X
>> variants and mpich / openmpi variants scattered throughout
On Jul 24, 2013, at 13:55, Sean Farley wrote:
> If the port wants to do something specialized then it could simply put
> the special code in an if-block:
>
> if {[variant_isset gcc46]} {
> ...
> }
That's true…
>> Setting compiler.blacklist as needed seems sufficient.
>
> What about your abov
ryandes...@macports.org writes:
> On Jul 20, 2013, at 18:28, Sean Farley wrote:
>
>> I'm looking for comments and feedback for two new port groups:
>> multiple compilers [1] and mpi [2]. My goal is to unify all the gcc4X
>> variants and mpich / openmpi variants scattered throughout the port
>> tr
On Jul 17, 2013, at 17:37, aron...@macports.org wrote:
> Revision: 108285
> https://trac.macports.org/changeset/108285
> Author: aron...@macports.org
> Date: 2013-07-17 15:37:30 -0700 (Wed, 17 Jul 2013)
> Log Message:
> ---
> wcstools: new port
>
> Programs for manipulatin
On Jul 22, 2013, at 6:37 PM, Frank Schima wrote:
> Maybe I was doing it wrong, but I was not able to get the patch to apply.
It requires a little more -p than usual…
% curl -s
'https://trac.macports.org/raw-attachment/ticket/39795/patch.py-obspy.diff' |
patch -d $(port dir py-obspy) -p4
On Jul 20, 2013, at 14:23, bl...@macports.org wrote:
> Revision: 108356
> https://trac.macports.org/changeset/108356
> Author: bl...@macports.org
> Date: 2013-07-20 12:23:26 -0700 (Sat, 20 Jul 2013)
> Log Message:
> ---
> autotrace, dvdauthor, inkscape, inkscape-devel, libd
On Jul 24, 2013, at 07:58, s...@macports.org wrote:
> Revision: 108487
> https://trac.macports.org/changeset/108487
> Author: s...@macports.org
> Date: 2013-07-24 05:58:31 -0700 (Wed, 24 Jul 2013)
> Log Message:
> ---
> pspp: update to 0.8.0
>
> Modified Paths:
> --
Original Message
> From: "Mojca Miklavec"
> Sent: Mittwoch, 24. Juli 2013 14:29
> To: ti...@v9g.de
> Subject: Re: request: bringing wxWidgets "up to date"
>
> On Wed, Jul 24, 2013 at 10:02 AM, Titus von Boxberg wrote:
> > Mojca, all,
> >
> > I don't have a solution for this prob
Hi,
On Wed, Jul 24, 2013 at 12:29:57PM +1000, Joshua Root wrote:
> That would break other modules, e.g. pyobjc.
Can you elaborate on how this would break pyobjc? If pyobjc doesn't work
with python +ucs4, its Portfile should use the active_variants PortGroup
and 'require_active_variants python${ve
Are all committers in holidays now ? :)
Le 22/07/13 13:25, Francois Claire a écrit :
Can someone please check ticket #39602 and commit the attached
Portfile/patches ?
Thanks in advance,
Francois.
___
macports-dev mailing list
macports-dev@lists.mac
On Wed, Jul 24, 2013 at 10:02 AM, Titus von Boxberg wrote:
> Mojca, all,
>
> I don't have a solution for this problem.
> Rather, I have a more fundamental question
> (which, however, may have been discussed already):
>
> Are there any interesting ports that are incompatible with 2.9
> and really ne
On 2013-7-24 18:57 , Ryan Schmidt wrote:
>
> On Jul 24, 2013, at 00:25, Lawrence Velázquez wrote:
>
>> On Jul 23, 2013, at 10:15 AM, Ryan Schmidt wrote:
>>
>>> On Jul 23, 2013, at 09:10, Ryan Schmidt wrote:
>>>
Is there a way -- command line flag or environment variable maybe -- to
ins
On Wed, Jul 24, 2013 at 10:48 AM, Ryan Schmidt wrote:
> On Jul 24, 2013, at 02:57, Mojca Miklavec wrote:
>
>> MacPorts provides a procedure
>>get_canonical_archflags
>> which returns "-arch i386 -arch x86_64". Is there any procedure that
>> would return "i386,x86_64" instead?
>
> The cmake port
On Jul 24, 2013, at 00:25, Lawrence Velázquez wrote:
> On Jul 23, 2013, at 10:15 AM, Ryan Schmidt wrote:
>
>> On Jul 23, 2013, at 09:10, Ryan Schmidt wrote:
>>
>>> Is there a way -- command line flag or environment variable maybe -- to
>>> instruct MacPorts not to do the Xcode license dance wh
On Jul 24, 2013, at 02:57, Mojca Miklavec wrote:
> MacPorts provides a procedure
>get_canonical_archflags
> which returns "-arch i386 -arch x86_64". Is there any procedure that
> would return "i386,x86_64" instead?
The cmake portgroup does:
configure.universal_args-append \
Mojca, all,
I don't have a solution for this problem.
Rather, I have a more fundamental question
(which, however, may have been discussed already):
Are there any interesting ports that are incompatible with 2.9
and really need to be compiled by macports?
Is 2.9 incompatible with any macports targ
Hi,
MacPorts provides a procedure
get_canonical_archflags
which returns "-arch i386 -arch x86_64". Is there any procedure that
would return "i386,x86_64" instead?
Thank you,
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
h
On Mon, Jul 22, 2013 at 6:16 PM, Mojca Miklavec wrote:
>
> 1.) How could I create a simple Portgroup that would define a variable
> or function
> wxwidgets.config (or confscript/configscript/wxconfig)
> whose value would be
> ${prefix}/lib/wx/config/mac-unicode-${installtype}-2.8
> in case
25 matches
Mail list logo
