On Jan 11, 2015, at 7:51 PM, MacPorts wrote:
>
> 1. Start with a new install of MacPorts or '''uninstall all ports that use
> C++'''
> 2. Install the libcxx port. When it activates, the libcxxabi and libcxx
> ports will install libc++.dylib and libc++abi.dylib (which will remain after
> you u
On Jan 11, 2015, at 2:46 PM, Brandon Allbery wrote:
> On Sun, Jan 11, 2015 at 2:43 PM, René J.V. wrote:
> My specific case (turned out to be moot) was that having QTDIR set in the
> environment might undo MacPorts' sandboxing attempts
>
> MacPorts nukes most user environment variables, doesn't
You likely have an outdated version of libunwind-headers. libunwind-headers
doesn't depend on CarbonHeaders as of some time in the past couple weeks.
--Jeremy
> On Jan 11, 2015, at 17:03, Michael F. Summers wrote:
>
> Colleagues,
>
> I also had to remove lib unwind-headers in order to be abl
On 12/01/2015, at 9:47 AM, René J.V. Bertin wrote:
> Ultimately you'll have /opt/local/libexec/qt4 and /opt/local/libexec/qt5 (and
> who knows, qt6 too).
> There really is no reason to worry. People on Linux have been going through
> those same
> motions for quite a while now.
OK. Thanks for cl
I'd like to obsolete the ports listed in the subject. They have no dependents
and the only references in other ports are listed conflicts.
https://trac.macports.org/ticket/46521
If I don't here a compelling reason as to why these need to stay, I intend to
obsolete them in a week.
--Jeremy
On Monday January 12 2015 09:30:08 Ian Wadham wrote:
> In case anyone does not already know, QTDIR is an env variable
> a developer can use when developing software based on Qt or
> a development (test, non-standard) version of Qt.
I doubt the variable is still required nowadays (which is not to
In case anyone does not already know, QTDIR is an env variable
a developer can use when developing software based on Qt or
a development (test, non-standard) version of Qt.
I always export QTDIR=/opt/local when I am developing or building
with a bleeding-edge version of KDE libraries, externally t
On Sun, Jan 11, 2015 at 4:43 PM, Ian Wadham wrote:
> OK, thanks. I was just checking… Yersinia pestis = bubonic plague (aka
> the Black Death),
> so an odd name for a piece of software.
>
I know. The SAINT white-hat vulnerability scanner was originally named
SATAN. The double-edged nature of s
On 12/01/2015, at 8:30 AM, Brandon Allbery wrote:
> On Sun, Jan 11, 2015 at 4:28 PM, Clemens Lang wrote:
> - On 11 Jan, 2015, at 22:21, Ian Wadham iandw...@gmail.com wrote:
> > Is there a good reason why we have the yersinia port on MacPorts? Please
> > read the description in full.
>
> I do
On Sun, Jan 11, 2015 at 4:28 PM, Clemens Lang wrote:
> - On 11 Jan, 2015, at 22:21, Ian Wadham iandw...@gmail.com wrote:
> > Is there a good reason why we have the yersinia port on MacPorts? Please
> > read the description in full.
>
> I don't see a problem with it? We have several other por
Hi,
- On 11 Jan, 2015, at 22:21, Ian Wadham iandw...@gmail.com wrote:
> Is there a good reason why we have the yersinia port on MacPorts? Please
> read the description in full.
I don't see a problem with it? We have several other ports related to
network security that could be equally disru
Hi guys,
Is there a good reason why we have the yersinia port on MacPorts? Please
read the description in full.
Best regards, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports
The leading colons denote a reference to a global variable.
If a Tcl command is evaluated in a tclsh at the top-level these
are not needed, on e.g. proc-scope these are required. It never
hurts to use it to make it clear one is referring to a global variable.
-g
Am 11.01.15 um 19:58 schrieb Ren
On Sunday January 11 2015 14:49:21 Michael Dickens wrote:
> PortGroup (qt4; I assume qt5 too), you'll see an "if" statement:
> {{{
> if {![info exists building_qt4]} {
> configure.env-append \
> QTDIR=${qt_dir} \
> QMAKE=${qt_qmake_cmd} \
> QMAKESPEC=${qt_qmake_spec} \
I spent a few days over the holidays getting libc++ working on Leopard/Intel.
Over the past week or so, I've tested this configuration and fixed various
issues that surfaced. As I now have all of my normal ports built and installed
on Leopard in this configuration, I think it's now ready for a
In my experience, we don't want QTDIR set when compiling Qt. Otherwise I
would not have included that variable (hack) in the first place. I can't
say what happens if it is set; don't remember any longer; probably Qt
just fails building.
My point was: If you trace the "building_qt#" variable throug
On Sun, Jan 11, 2015 at 2:43 PM, René J.V. wrote:
> My specific case (turned out to be moot) was that having QTDIR set in the
> environment might undo MacPorts' sandboxing attempts
MacPorts nukes most user environment variables, doesn't it, precisely for
that reason?
--
brandon s allbery kf8n
On Sunday January 11 2015 14:26:45 Michael Dickens wrote:
Hi Michael
> This variable is designed just for the purpose you need for qt4-mac; it
> would not be difficult to add to qt5-mac if it is not already in place.
> There's probably a better way to do this, but using a simple variable is
> qui
>From the top of the qt4-mac Portfile:
{{{
# use the qt4 group; set 'building_qt4' so that the portgroup
# does not include certain parts
set building_qt41
}}}
This variable is designed just for the purpose you need for qt4-mac; it
would not be difficult to add to qt5-mac if it is not already i
On Sunday January 11 2015 18:01:06 Gustaf Neumann wrote:
> > Is there a (Tcl) command one can use to set or unset variables at an
> > appropriate point
>
> set environment variable
> set ::env(FOO) "some value"
>
> unset environment variable
> unset ::env(FOO)
Thanks :)
Is the namespa
Is there a (Tcl) command one can use to set or unset variables at an
appropriate point
set environment variable
set ::env(FOO) "some value"
unset environment variable
unset ::env(FOO)
-g
___
macports-dev mailing list
macports-dev@lists.macos
Hi,
I see MacPorts provides a set of keywords to add or delete env. variables to or
from specific phases. Is there a (Tcl) command one can use to set or unset
variables at an appropriate point so it's defined (or missing) appropriately
for all subsequent steps?
If not, can one use *.env-delete
I spent a few days over the holidays getting libc++ working on Leopard/Intel.
Over the past week or so, I've tested this configuration and fixed various
issues that surfaced. As I now have all of my normal ports built and installed
on Leopard in this configuration, I think it's now ready for a
23 matches
Mail list logo
