Hi Sean - Some Python ports require these variables to be set in
multiple phases. I don't think setting them in multiple phases hurts the
other ports (those that get the flags during configure or build, and
don't use them in any other phase). Things seem to work right now, and
adding these variable
Is there any reason that the configure.env variables are automatically
copied to the build and destroot phases?
I ask because most python packages do not use the traditional
'./configure; make; make install' method and instead set things like the
prefix and whatnot in the build or destroot phase.
opriately for all subsequent steps?
The environment variables have to be set explicitly. Usually it is
enough to define them for the configure phase, but that depends on the
build system.
> If not, can one use *.env-delete to unset a variable without knowing
> its value?
There is currently no w
On 2015-01-11 18:01, 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)
Portfiles do not use the normal environ
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 e
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
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
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} \
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?
--
b
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
On 2013-10-1 01:20 , Peter Danecek wrote:
>
> Well, if I am now understanding right, for perl, ar, randlib are not set to
> default values by macports. Is it save to point these to the systems provided
> versions with the absolute path?
>
> something like:
> PERL=/usr/bin/perl
> AR=/usr/bin
On Sep 30, 2013, at 10:20, Peter Danecek wrote:
> Well, if I am now understanding right, for perl, ar, randlib are not set to
> default values by macports.
That's right.
> Is it save to point these to the systems provided versions with the absolute
> path?
>
> something like:
> PERL=/usr/b
R, PERL, etc.,
>> but does not respect the setting for environment variables.
>>
>> During configure phase macports sets such environment variables, right? In
>> particular I am aware of the ones for the compilers to use. However,
>> searching the documenta
On 2013-10-1 00:17 , Peter Danecek wrote:
>
> Hi all,
>
> I am currently trying to setup a port. The "configure script" (not a standard
> GNU approach) does set makefile variables for CC, AR, PERL, etc., but does
> not respect the setting for environment variables.
On Mon, Sep 30, 2013 at 04:17:03PM +0200, Peter Danecek wrote:
> During configure phase macports sets such environment variables,
> right? In particular I am aware of the ones for the compilers to use.
> However, searching the documentation I have not found a comprehensive.
> Does
Hi all,
I am currently trying to setup a port. The "configure script" (not a standard
GNU approach) does set makefile variables for CC, AR, PERL, etc., but does not
respect the setting for environment variables.
During configure phase macports sets such environment variables,
23 matches
Mail list logo