Re: declaring variants/subports in loops and loop variables

[Joshua Root]

On 2016-12-8 04:51 , René J.V. Bertin wrote:

On Wednesday December 07 2016 17:09:35 Brandon Allbery wrote:


Use a double quoted string and escape anything that needs it (but
specifically not those variables for which you need the current value).


I don't think that's going to make things much more readable, would it?

I did notice one sometimes has to do this with the variant description (variant foo 
description "bla bla") but

variant foo description "bla bla" "
\variant \stuff \here \
"

doesn't really help (me).


Yes it does. (The variant's description is completely irrelevant to the 
problem though.) Your original example was:


{{{
set pythonversions {3.4 3.5}
foreach pdv ${pythonversions} {
set pv [join [lrange [split ${pdv} .] 0 1] ""]
# snip
variant python${pv} description "Add bindings for Python ${pdv}" {
depends_libs-append port:python${pv}
# snip
}
}
}}}

Changing that to this will solve the problem:
{{{
set pythonversions {3.4 3.5}
foreach pdv ${pythonversions} {
set pv [join [lrange [split ${pdv} .] 0 1] ""]
# snip
variant python${pv} description "Add bindings for Python ${pdv}" "
depends_libs-append port:python${pv}
# snip
"
}
}}}


That [adding global foo] would do a different wrong thing, specifically the one 
you originally
complained about.


I though Joshua's intention was to show that the two procedures print the last 
known value of foo, not that they complain about an unknown variable because 
they expect it in their local frame.


No, my intention was to show that the variable is not in the correct 
scope. Adding a global declaration would still illustrate that but in a 
less obvious way.


- Josh

Re: Criteria for picking compilers from fallback list ?

[Jeremy Huddleston Sequoia]

> On Dec 7, 2016, at 11:43, Christopher Jones  wrote:
> 
> Hi,
> 
> Ah I see now. The differences come from the fact I append to the fallback 
> list, rather than set it. I think I will update the port to explicitly set 
> the fallback list, so wipe out the defaults, to thus get consistent behaviour 
> across the OSX versions.

If you want it to be explicit, set the whitelist directly, not the fallback 
list.

> 
> cheers Chris
> 
>> On 7 Dec 2016, at 7:15 pm, Ryan Schmidt  wrote:
>> 
>>> 
>>> On Dec 7, 2016, at 12:05 PM, Christopher Jones  
>>> wrote:
>>> 
>>> 
 On 7 Dec 2016, at 5:32 pm, Joshua Root  wrote:
 
 On 2016-12-8 04:24 , Chris Jones wrote:
> Hi,
> 
> I'm working on an update to the root6 port, where the minimum compiler
> requirement has been increased in the latest release, such that I need
> to update the compiler blacklist/fallback to force a macports compiler
> to be used on OSX 10.8 and 10.9 (whereas previously the system one was 
> OK).
> 
> This is all working OK, but I have noticed one thing I am trying to
> understand is on 10.8 and 10.9 different fallbacks are being picked.
> 
> I have
> 
> compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
> macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
> compiler.fallback-append macports-clang-3.9 macports-clang-3.8
> macports-clang-3.7
> 
> On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
> clang 3.8 is being used. I am curious as to what the logic is in the
> blacklist portgroup that is leading to this different decisions to be
> made ? I thought perhaps it was based on what clang ports where already
> installed, but even after uninstalling all clang versions, the same
> decisions are being made. Just curious...
 
 The initial value of compiler.fallback differs based on cxx_stdlib because 
 clang 3.5+ needs libc++. And yes, this will mean trouble for users on 10.8 
 who are using the default cxx_stdlib.
>>> 
>>> Ah, I didn’t consider the cxx_stdlib differences. Still not sure though how 
>>> that exactly translates into different decisions w.r.t. clang 3.8 versus 
>>> 3.9 though. Is it just the different list means a different (random) 
>>> decision is taken ? both are >3.5 so on the same field regarding the stdlib 
>>> used.
>> 
>> No random decisions are taken. MacPorts uses the first acceptable (i.e. not 
>> blacklisted) compiler from the whitelist (if you specify a whitelist), or 
>> the first acceptable compiler from the fallback list (if you don't specify a 
>> whitelist).
>> 
>> You can read the portconfigure::get_compiler_fallback procedure in 
>> src/port1.0/portconfigure.tcl to see all the nuance that goes into 
>> generating the list of compilers to try, which varies based on OS version, 
>> Xcode version, and C++ library:
>> 
>> https://github.com/macports/macports-base/blob/7fb6ab2e5a40a5f4f828430a499b840b43398c56/src/port1.0/portconfigure.tcl#L475
>> 
>> but the relevant part here is:
>> 
>> On OS X versions earlier than Sierra, with libc++ and Xcode 5 or later (i.e. 
>> on 10.9-10.11, or on 10.8 or earlier if the user follows the 
>> LibcxxOnOlderSystems wiki page) the default compiler fallback is:
>> 
>> clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
>> macports-clang-3.5
>> 
>> (The intention is that this would list the newest stable version of clang 
>> first, followed by the next newest stable version, etc. clang 3.9.0 stable 
>> was released in September 2016 so one would think that macports-clang-3.9 
>> should be prepended to that list, but we haven't done that yet; I don't know 
>> if there is an extenuating circumstance why that has not yet been done.)
>> 
>> With libstdc++ and Xcode 5 or later, the default compiler fallback is:
>> 
>> clang macports-clang-3.4 macports-clang-3.3
>> 
>> To these lists, in your port you append "macports-clang-3.9 
>> macports-clang-3.8 macports-clang-3.7"
>> 
>> That means the final fallback list for your port for libc++ on 10.11 or 
>> earlier with Xcode 5 or later is:
>> 
>> clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
>> macports-clang-3.5 macports-clang-3.9 macports-clang-3.8 macports-clang-3.7
>> 
>> From this, MacPorts picks the first acceptable compiler, which (since you 
>> are blacklisting clang < 602) is either clang (if its version is >= 602) or 
>> macports-clang-3.8 (if clang's version is < 602).
>> 
>> For libstdc++ with Xcode 5 or later, the final fallback for your port is:
>> 
>> clang macports-clang-3.4 macports-clang-3.3 macports-clang-3.9 
>> macports-clang-3.8 macports-clang-3.7
>> 
>> (For earlier Xcode versions, llvm-gcc-4.2 is also in the list, but since 
>> you're blacklisting *gcc* that won't get used.)
>> 
>> From this, MacPorts picks the first acceptable compiler, 

Re: Criteria for picking compilers from fallback list ?

[Jeremy Huddleston Sequoia]

> On Dec 7, 2016, at 11:15, Ryan Schmidt  wrote:
> 
> 
>> On Dec 7, 2016, at 12:05 PM, Christopher Jones  
>> wrote:
>> 
>> 
>>> On 7 Dec 2016, at 5:32 pm, Joshua Root  wrote:
>>> 
>>> On 2016-12-8 04:24 , Chris Jones wrote:
 Hi,
 
 I'm working on an update to the root6 port, where the minimum compiler
 requirement has been increased in the latest release, such that I need
 to update the compiler blacklist/fallback to force a macports compiler
 to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).
 
 This is all working OK, but I have noticed one thing I am trying to
 understand is on 10.8 and 10.9 different fallbacks are being picked.
 
 I have
 
 compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
 macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
 compiler.fallback-append macports-clang-3.9 macports-clang-3.8
 macports-clang-3.7
 
 On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
 clang 3.8 is being used. I am curious as to what the logic is in the
 blacklist portgroup that is leading to this different decisions to be
 made ? I thought perhaps it was based on what clang ports where already
 installed, but even after uninstalling all clang versions, the same
 decisions are being made. Just curious...
>>> 
>>> The initial value of compiler.fallback differs based on cxx_stdlib because 
>>> clang 3.5+ needs libc++. And yes, this will mean trouble for users on 10.8 
>>> who are using the default cxx_stdlib.
>> 
>> Ah, I didn’t consider the cxx_stdlib differences. Still not sure though how 
>> that exactly translates into different decisions w.r.t. clang 3.8 versus 3.9 
>> though. Is it just the different list means a different (random) decision is 
>> taken ? both are >3.5 so on the same field regarding the stdlib used.
> 
> No random decisions are taken. MacPorts uses the first acceptable (i.e. not 
> blacklisted) compiler from the whitelist (if you specify a whitelist), or the 
> first acceptable compiler from the fallback list (if you don't specify a 
> whitelist).
> 
> You can read the portconfigure::get_compiler_fallback procedure in 
> src/port1.0/portconfigure.tcl to see all the nuance that goes into generating 
> the list of compilers to try, which varies based on OS version, Xcode 
> version, and C++ library:
> 
> https://github.com/macports/macports-base/blob/7fb6ab2e5a40a5f4f828430a499b840b43398c56/src/port1.0/portconfigure.tcl#L475
> 
> but the relevant part here is:
> 
> On OS X versions earlier than Sierra, with libc++ and Xcode 5 or later (i.e. 
> on 10.9-10.11, or on 10.8 or earlier if the user follows the 
> LibcxxOnOlderSystems wiki page) the default compiler fallback is:
> 
> clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
> macports-clang-3.5
> 
> (The intention is that this would list the newest stable version of clang 
> first, followed by the next newest stable version, etc. clang 3.9.0 stable 
> was released in September 2016 so one would think that macports-clang-3.9 
> should be prepended to that list, but we haven't done that yet; I don't know 
> if there is an extenuating circumstance why that has not yet been done.)

Waiting for 3.9.1.
3.9+ also doesn't currently build on Snow Leopard and earlier.

I'd like to get those taken care of first.


> With libstdc++ and Xcode 5 or later, the default compiler fallback is:
> 
> clang macports-clang-3.4 macports-clang-3.3
> 
> To these lists, in your port you append "macports-clang-3.9 
> macports-clang-3.8 macports-clang-3.7"
> 
> That means the final fallback list for your port for libc++ on 10.11 or 
> earlier with Xcode 5 or later is:
> 
> clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
> macports-clang-3.5 macports-clang-3.9 macports-clang-3.8 macports-clang-3.7
> 
> From this, MacPorts picks the first acceptable compiler, which (since you are 
> blacklisting clang < 602) is either clang (if its version is >= 602) or 
> macports-clang-3.8 (if clang's version is < 602).
> 
> For libstdc++ with Xcode 5 or later, the final fallback for your port is:
> 
> clang macports-clang-3.4 macports-clang-3.3 macports-clang-3.9 
> macports-clang-3.8 macports-clang-3.7
> 
> (For earlier Xcode versions, llvm-gcc-4.2 is also in the list, but since 
> you're blacklisting *gcc* that won't get used.)
> 
> From this, MacPorts picks the first acceptable compiler, which (since you are 
> blacklisting clang < 602 and macports-clang-3.3 and macports-clang-3.4) is 
> macports-clang-3.9.
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Question about bootstrapping MinGW

[Mojca Miklavec]

Hi,

I have finally managed to come up with ports for MinGW-w64. It seems
to work as expected except for a tiny problem: gcc has to be compiled
in two stages. The first stage installs the bootstrapped version of
the compiler and the second stage installs everything (else).

I created two subports (it would have to be three if support for
pthreads is required):
x86_64-w64-mingw32-gcc
x86_64-w64-mingw32-all
(suggestions for better names welcome, I don't particularly like
"-all", maybe the first one could be "-gcc-bootstrap" and the second
one simply "-gcc").

The first one does "make all-gcc && make install-gcc".
The last one does "make && make install" on the same sources (after
the same configure), except that the second one needs additional
dependencies to complete.

(The intermediate port would do "make all-target-libgcc && make
install-target-libgcc" if it was required.)

The problem is that both subports install the same files (the
bootstrapped version installs a subset). I'm not sure if the
overlapping files are actually the same or not. Maybe I could do some
testing with binary comparison (like the one Clemens presented at the
meeting), upstream suggested to use the result of the final "make
install" rather than the bootstrapped files.

How could I solve that? A few things come to mind.

(1) In a post-destroot phase of the second subport ("-all") iterate
through the installed files and delete all the files that were already
installed by the bootstrapping port ("-gcc"). A potential disadvantage
might be that those files might not be the same. But I would have to
double check that.

(2) Install the bootstrapping port to a completely different location.
Slightly more annoying to implement.

(3) I tried the deactivate hack:

  set mingw_target x86_64-w64-mingw32
  set mingw_gcc_bootstrap ${mingw_target}-gcc

  subport ${mingw_target}-all {
  depends_build-append \
  port:${mingw_target}-crt \
  bin:${mingw_target}-gcc:${mingw_target}-gcc

  pre-activate {
  if {![catch {set installed [lindex [registry_active
${mingw_gcc_bootstrap}] 0]}]} {
  registry_deactivate_composite ${mingw_gcc_bootstrap} ""
[list ports_nodepcheck 1]
  }
  }
  }

Maybe I added this to the port too late (I added it once I already had
it destrooted and manually forced-deactivated x86_64-w64-mingw32-gcc
first), but it insisted that I should have installed
x86_64-w64-mingw32-gcc before activating x86_64-w64-mingw32-all. I'll
try it once again. I'm not sure if this is something that is supposed
to work at all.

Which one sounds best? Or perhaps there are other better options?


A few other questions.

What's the proper licence for x86_64-w64-mingw32-gcc? The portgroup
seems to set GPL-3+, while gcc6 has {GPL-3+ Permissive}.

I would be also grateful for hints about the licence of headers and crt:
https://github.com/mirror/mingw-w64/blob/master/COPYING

Thank you,
Mojca

Re: Criteria for picking compilers from fallback list ?

[Christopher Jones]

Hi,

Ah I see now. The differences come from the fact I append to the fallback list, 
rather than set it. I think I will update the port to explicitly set the 
fallback list, so wipe out the defaults, to thus get consistent behaviour 
across the OSX versions.

cheers Chris

> On 7 Dec 2016, at 7:15 pm, Ryan Schmidt  wrote:
> 
>> 
>> On Dec 7, 2016, at 12:05 PM, Christopher Jones  
>> wrote:
>> 
>> 
>>> On 7 Dec 2016, at 5:32 pm, Joshua Root  wrote:
>>> 
>>> On 2016-12-8 04:24 , Chris Jones wrote:
 Hi,
 
 I'm working on an update to the root6 port, where the minimum compiler
 requirement has been increased in the latest release, such that I need
 to update the compiler blacklist/fallback to force a macports compiler
 to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).
 
 This is all working OK, but I have noticed one thing I am trying to
 understand is on 10.8 and 10.9 different fallbacks are being picked.
 
 I have
 
 compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
 macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
 compiler.fallback-append macports-clang-3.9 macports-clang-3.8
 macports-clang-3.7
 
 On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
 clang 3.8 is being used. I am curious as to what the logic is in the
 blacklist portgroup that is leading to this different decisions to be
 made ? I thought perhaps it was based on what clang ports where already
 installed, but even after uninstalling all clang versions, the same
 decisions are being made. Just curious...
>>> 
>>> The initial value of compiler.fallback differs based on cxx_stdlib because 
>>> clang 3.5+ needs libc++. And yes, this will mean trouble for users on 10.8 
>>> who are using the default cxx_stdlib.
>> 
>> Ah, I didn’t consider the cxx_stdlib differences. Still not sure though how 
>> that exactly translates into different decisions w.r.t. clang 3.8 versus 3.9 
>> though. Is it just the different list means a different (random) decision is 
>> taken ? both are >3.5 so on the same field regarding the stdlib used.
> 
> No random decisions are taken. MacPorts uses the first acceptable (i.e. not 
> blacklisted) compiler from the whitelist (if you specify a whitelist), or the 
> first acceptable compiler from the fallback list (if you don't specify a 
> whitelist).
> 
> You can read the portconfigure::get_compiler_fallback procedure in 
> src/port1.0/portconfigure.tcl to see all the nuance that goes into generating 
> the list of compilers to try, which varies based on OS version, Xcode 
> version, and C++ library:
> 
> https://github.com/macports/macports-base/blob/7fb6ab2e5a40a5f4f828430a499b840b43398c56/src/port1.0/portconfigure.tcl#L475
>  
> 
> 
> but the relevant part here is:
> 
> On OS X versions earlier than Sierra, with libc++ and Xcode 5 or later (i.e. 
> on 10.9-10.11, or on 10.8 or earlier if the user follows the 
> LibcxxOnOlderSystems wiki page) the default compiler fallback is:
> 
> clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
> macports-clang-3.5
> 
> (The intention is that this would list the newest stable version of clang 
> first, followed by the next newest stable version, etc. clang 3.9.0 stable 
> was released in September 2016 so one would think that macports-clang-3.9 
> should be prepended to that list, but we haven't done that yet; I don't know 
> if there is an extenuating circumstance why that has not yet been done.)
> 
> With libstdc++ and Xcode 5 or later, the default compiler fallback is:
> 
> clang macports-clang-3.4 macports-clang-3.3
> 
> To these lists, in your port you append "macports-clang-3.9 
> macports-clang-3.8 macports-clang-3.7"
> 
> That means the final fallback list for your port for libc++ on 10.11 or 
> earlier with Xcode 5 or later is:
> 
> clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
> macports-clang-3.5 macports-clang-3.9 macports-clang-3.8 macports-clang-3.7
> 
> From this, MacPorts picks the first acceptable compiler, which (since you are 
> blacklisting clang < 602) is either clang (if its version is >= 602) or 
> macports-clang-3.8 (if clang's version is < 602).
> 
> For libstdc++ with Xcode 5 or later, the final fallback for your port is:
> 
> clang macports-clang-3.4 macports-clang-3.3 macports-clang-3.9 
> macports-clang-3.8 macports-clang-3.7
> 
> (For earlier Xcode versions, llvm-gcc-4.2 is also in the list, but since 
> you're blacklisting *gcc* that won't get used.)
> 
> From this, MacPorts picks the first acceptable compiler, which (since you are 
> blacklisting clang < 602 and macports-clang-3.3 and macports-clang-3.4) is 
> macports-clang-3.9.



smime.p7s
Description: S/MIME 

Re: `port edit`, local/console vs. remote use

[Bradley Giesbrecht]

> On Dec 7, 2016, at 1:26 AM, René J.V. Bertin  wrote:
> 
> On Tuesday December 6 2016 11:41:39 Ryan Schmidt wrote:
> 
>> I haven't taken the time to look into how I could configure that. So 
>> instead, I configure EDITOR to run TextWrangler, and whenever I ssh in and 
>> need to edit a portfile, which is rare, I use 'vi $(port file someport)` 
>> instead of `port edit someport`. 
> 
> I often use `port edit --editor XX foo` when I don't want to use the default 
> editor. Maybe the cleanest solution would be to add a short option equivalent 
> of `port edit --editor vi`. I'd say `port edit -v` as a mnemonic, but that 
> could cause confusion with the verbose option. 
> 
> Either way this could serve users like Ryan and me:
> 
> - A new MP_GUI_EDITOR variable contains the name of the preferred/GUI editor 
> that cannot be used over ssh
> - `port edit` uses that value if available unless an option is given to 
> override this choice
> - nothing else changes
> 
> VISUAL_EDITOR could be used instead of MP_GUI_EDITOR but we don't know how 
> many people use that variable.
> 
> A possible suitable choice for the short option: -f, as in "force editing 
> even if your usual editor isn't available". In that case the option could 
> override all env. variables with the possible exception of VISUAL_EDITOR if 
> that's a traditional variable also used outside of MacPorts.

I have this in .bash_profile:
...
if [ "${SSH_TTY+1}" ];then
export EDITOR=nano
else
export EDITOR=bbedit
 fi
...

echo $EDITOR
ssh localhost
echo $EDITOR


Regards,
Bradley Giesbrecht (pixilla)

Re: Criteria for picking compilers from fallback list ?

[Ryan Schmidt]

> On Dec 7, 2016, at 12:05 PM, Christopher Jones  
> wrote:
> 
> 
>> On 7 Dec 2016, at 5:32 pm, Joshua Root  wrote:
>> 
>> On 2016-12-8 04:24 , Chris Jones wrote:
>>> Hi,
>>> 
>>> I'm working on an update to the root6 port, where the minimum compiler
>>> requirement has been increased in the latest release, such that I need
>>> to update the compiler blacklist/fallback to force a macports compiler
>>> to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).
>>> 
>>> This is all working OK, but I have noticed one thing I am trying to
>>> understand is on 10.8 and 10.9 different fallbacks are being picked.
>>> 
>>> I have
>>> 
>>> compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
>>> macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
>>> compiler.fallback-append macports-clang-3.9 macports-clang-3.8
>>> macports-clang-3.7
>>> 
>>> On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
>>> clang 3.8 is being used. I am curious as to what the logic is in the
>>> blacklist portgroup that is leading to this different decisions to be
>>> made ? I thought perhaps it was based on what clang ports where already
>>> installed, but even after uninstalling all clang versions, the same
>>> decisions are being made. Just curious...
>> 
>> The initial value of compiler.fallback differs based on cxx_stdlib because 
>> clang 3.5+ needs libc++. And yes, this will mean trouble for users on 10.8 
>> who are using the default cxx_stdlib.
> 
> Ah, I didn’t consider the cxx_stdlib differences. Still not sure though how 
> that exactly translates into different decisions w.r.t. clang 3.8 versus 3.9 
> though. Is it just the different list means a different (random) decision is 
> taken ? both are >3.5 so on the same field regarding the stdlib used.

No random decisions are taken. MacPorts uses the first acceptable (i.e. not 
blacklisted) compiler from the whitelist (if you specify a whitelist), or the 
first acceptable compiler from the fallback list (if you don't specify a 
whitelist).

You can read the portconfigure::get_compiler_fallback procedure in 
src/port1.0/portconfigure.tcl to see all the nuance that goes into generating 
the list of compilers to try, which varies based on OS version, Xcode version, 
and C++ library:

https://github.com/macports/macports-base/blob/7fb6ab2e5a40a5f4f828430a499b840b43398c56/src/port1.0/portconfigure.tcl#L475

but the relevant part here is:

On OS X versions earlier than Sierra, with libc++ and Xcode 5 or later (i.e. on 
10.9-10.11, or on 10.8 or earlier if the user follows the LibcxxOnOlderSystems 
wiki page) the default compiler fallback is:

clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
macports-clang-3.5

(The intention is that this would list the newest stable version of clang 
first, followed by the next newest stable version, etc. clang 3.9.0 stable was 
released in September 2016 so one would think that macports-clang-3.9 should be 
prepended to that list, but we haven't done that yet; I don't know if there is 
an extenuating circumstance why that has not yet been done.)

With libstdc++ and Xcode 5 or later, the default compiler fallback is:

clang macports-clang-3.4 macports-clang-3.3

To these lists, in your port you append "macports-clang-3.9 macports-clang-3.8 
macports-clang-3.7"

That means the final fallback list for your port for libc++ on 10.11 or earlier 
with Xcode 5 or later is:

clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
macports-clang-3.5 macports-clang-3.9 macports-clang-3.8 macports-clang-3.7

From this, MacPorts picks the first acceptable compiler, which (since you are 
blacklisting clang < 602) is either clang (if its version is >= 602) or 
macports-clang-3.8 (if clang's version is < 602).

For libstdc++ with Xcode 5 or later, the final fallback for your port is:

clang macports-clang-3.4 macports-clang-3.3 macports-clang-3.9 
macports-clang-3.8 macports-clang-3.7

(For earlier Xcode versions, llvm-gcc-4.2 is also in the list, but since you're 
blacklisting *gcc* that won't get used.)

From this, MacPorts picks the first acceptable compiler, which (since you are 
blacklisting clang < 602 and macports-clang-3.3 and macports-clang-3.4) is 
macports-clang-3.9.

Re: declaring variants/subports in loops and loop variables

[Brandon Allbery]

On Wed, Dec 7, 2016 at 6:42 PM, René J.V. Bertin 
wrote:

> My experience with Python (even from the rather early 2.x days in the late
> 90s) is that it's always been very strict about scoping and closures


Oh, it's strict enough, it just doesn't *have* some kinds of scope.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: declaring variants/subports in loops and loop variables

[René J . V . Bertin]

On Wednesday December 07 2016 18:35:04 Brandon Allbery wrote:

> (iirc you can get into the same mess with python 2, although maybe not in
> 2.7)

My experience with Python (even from the rather early 2.x days in the late 90s) 
is that it's always been very strict about scoping and closures. But I don't 
think I've ever used it to write self-modifying code (maybe not exactly what 
we're discussing here, but it's certainly evoked in my mind).

R.

Re: declaring variants/subports in loops and loop variables

[René J . V . Bertin]

On Wednesday December 07 2016 17:56:56 Brandon Allbery wrote:

> It won't, but that's the best you will do in a stringy language like Tcl
> (or shells, for that matter).

Fortunately there's also the alternative of using an if construct inside the 
loop, which does work as expected.


> > Not "which ones", just `uplevel 1 $code`, just like `proc platform` does.
> >
> 
> I don't think that will work; you're looking for a closure here where $pv
> and $pdv are captured from where the variant is declared, and any other $s
> are either local or uplevel-ed to where the variant is *run* from.

In this case it indeed won't work because $code is not evaluated immediately 
inside `proc variant` but is instead used to create a procedure that's invoked 
if the user activates a variant. I haven't tried to figure out exactly how that 
happens, but apparently it's after the loop has terminated. Probably after the 
initial parsing run of the Portfile:

{{{
foreach pdv ${pythonversions} {
set pv [join [lrange [split ${pdv} .] 0 1] ""]
variant python${pv} conflicts ${conflist} description "Add bindings for 
Python ${pdv}" {
ui_msg "variant ${pv} is being defined"
}
# settings that depend on loop variables must be set in an appropriate if, 
not in the
# variant declaration scope.
if {[variant_isset python${pv}]} {
ui_msg "variant_isset ${pv}"
}
}
#snip
ui_msg "done"

}}}

{{{
%> port info opencv +python34
variant_isset 34
done
variant 35 is being defined
opencv @3.1.0_6 (graphics, science)
}}}


Now I also understand other idiosyncrasies I've run into and resolved by moving 
expressions from the variant "body" to scopes conditional on variant_isset in 
order to be certain of the evaluation order.

Cf. a procedure I defined for those of my KF5 ports that need a variant to 
co-install with their KDE4 counterpart 
(https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/kf5-1.1.tcl#L697).
 Not relevant for the initial thread topic, just something that gives a clean 
way to declare a variant as well as code to be executed when the variant is set 
or when it's not, in such a way that the code can assume that the current state 
corresponds to what can be inferred from the location in the Portfile.

R

Re: Criteria for picking compilers from fallback list ?

[Christopher Jones]

> On 7 Dec 2016, at 5:32 pm, Joshua Root  wrote:
> 
> On 2016-12-8 04:24 , Chris Jones wrote:
>> Hi,
>> 
>> I'm working on an update to the root6 port, where the minimum compiler
>> requirement has been increased in the latest release, such that I need
>> to update the compiler blacklist/fallback to force a macports compiler
>> to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).
>> 
>> This is all working OK, but I have noticed one thing I am trying to
>> understand is on 10.8 and 10.9 different fallbacks are being picked.
>> 
>> I have
>> 
>> compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
>> macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
>> compiler.fallback-append macports-clang-3.9 macports-clang-3.8
>> macports-clang-3.7
>> 
>> On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
>> clang 3.8 is being used. I am curious as to what the logic is in the
>> blacklist portgroup that is leading to this different decisions to be
>> made ? I thought perhaps it was based on what clang ports where already
>> installed, but even after uninstalling all clang versions, the same
>> decisions are being made. Just curious...
> 
> The initial value of compiler.fallback differs based on cxx_stdlib because 
> clang 3.5+ needs libc++. And yes, this will mean trouble for users on 10.8 
> who are using the default cxx_stdlib.

Ah, I didn’t consider the cxx_stdlib differences. Still not sure though how 
that exactly translates into different decisions w.r.t. clang 3.8 versus 3.9 
though. Is it just the different list means a different (random) decision is 
taken ? both are >3.5 so on the same field regarding the stdlib used.

Chris

> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature

Re: declaring variants/subports in loops and loop variables

[René J . V . Bertin]

On Wednesday December 07 2016 17:09:35 Brandon Allbery wrote:

> Use a double quoted string and escape anything that needs it (but
> specifically not those variables for which you need the current value).

I don't think that's going to make things much more readable, would it?

I did notice one sometimes has to do this with the variant description (variant 
foo description "bla bla") but 

variant foo description "bla bla" "
\variant \stuff \here \
"

doesn't really help (me).


> That [adding global foo] would do a different wrong thing, specifically the 
> one you originally
> complained about.

I though Joshua's intention was to show that the two procedures print the last 
known value of foo, not that they complain about an unknown variable because 
they expect it in their local frame.

> How would it know which ones to uplevel?

Not "which ones", just `uplevel 1 $code`, just like `proc platform` does.

R

Re: declaring variants/subports in loops and loop variables

[Brandon Allbery]

On Wed, Dec 7, 2016 at 5:51 PM, René J.V. Bertin 
wrote:

> On Wednesday December 07 2016 17:09:35 Brandon Allbery wrote:
> > Use a double quoted string and escape anything that needs it (but
> > specifically not those variables for which you need the current value).
>
> I don't think that's going to make things much more readable, would it?
>

It won't, but that's the best you will do in a stringy language like Tcl
(or shells, for that matter).

> How would it know which ones to uplevel?
>
> Not "which ones", just `uplevel 1 $code`, just like `proc platform` does.
>

I don't think that will work; you're looking for a closure here where $pv
and $pdv are captured from where the variant is declared, and any other $s
are either local or uplevel-ed to where the variant is *run* from.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: declaring variants/subports in loops and loop variables

[Brandon Allbery]

On Wed, Dec 7, 2016 at 5:42 PM, René J.V. Bertin 
wrote:

> > This is almost exactly the same situation as:
> >
> > foreach foo {bar baz} {
> >   proc p_$foo {} {
> >   puts $foo
> >   }
> > }
> > p_bar
> > p_baz
>
> Huh? This complains about foo not being known, I think there should be a
> `global foo` in that procedure?
>

That would do a different wrong thing, specifically the one you originally
complained about.

> I was expecting something like that but apparently this is not achieved
via uplevel in `proc variant`?

How would it know which ones to uplevel?

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: declaring variants/subports in loops and loop variables

[René J . V . Bertin]

On Thursday December 08 2016 04:04:57 Joshua Root wrote:

> This is almost exactly the same situation as:
> 
> foreach foo {bar baz} {
>   proc p_$foo {} {
>   puts $foo
>   }
> }
> p_bar
> p_baz

Huh? This complains about foo not being known, I think there should be a 
`global foo` in that procedure?

> (Variants are slightly different only in that they 
> automagically bring all global variables into scope. Thus you get pv 
> with its current value instead of a "no such variable" error.)

I was expecting something like that but apparently this is not achieved via 
uplevel in `proc variant`?

Josh, I think you're the in-house Tcl guru. Out of curiosity, would it be 
feasible to write a foreach wrapper that makes limits the lifetime of the loop 
variable and all newly declared variables to the loop scope (like in C/C++)? 
And would such a wrapper be useful in the kind of context at hand (or would it 
have too many unwanted side-effects)?

> That sounds overly complicated (there should be almost no reason to use 
> eval, ever.) Quotes instead of braces would allow variable substitution 
> in the variant body.

I also spoke too soon that it did the trick. I'm using 
configure.args-{delete,replace,append} in the variant, and this doesn't work 
properly.

Still referring to the opencv Portfile from the referenced trac ticket, if I do 

{{{
eval [subst {
variant python${pv} conflicts ${conflist} description "Add bindings for 
Python ${pdv}" {
patchfiles-delete   patch-modules_python_CMakeLists.txt.diff
configure.args-delete \
-DINSTALL_PYTHON_EXAMPLES=OFF \
-DBUILD_opencv_python3=OFF
depends_lib-append  port:python${pv} \
port:py${pv}-numpy
if {![variant_isset python27]} {
configure.args-replace \
-DPYTHON_EXECUTABLE=OFF \
-DPYTHON_EXECUTABLE=${prefix}/bin/python${pdv}
}
configure.args-append \
-DINSTALL_PYTHON_EXAMPLES=ON \
-DPYTHON3_EXECUTABLE=${prefix}/bin/python${pdv} \

-DPYTHON3_LIBRARY=${frameworks_dir}/Python.framework/Versions/${pdv}/lib/libpython${pdv}.dylib
 \

-DPYTHON3_INCLUDE_DIR=${frameworks_dir}/Python.framework/Versions/${pdv}/Headers
 \

-DPYTHON3_PACKAGES_PATH=${frameworks_dir}/Python.framework/Versions/${pdv}/lib/python${pdv}/site-packages
ui_msg "${configure.args}"
}
}]
}}}

I get

{{{
%> port info opencv +python34
-DCMAKE_BUILD_TYPE=MacPorts -DWITH_1394=OFF -DWITH_CARBON=OFF -DWITH_VTK=OFF 
-DWITH_CUDA=OFF -DWITH_CUFFT=OFF -DWITH_CUBLAS=OFF -DWITH_EIGEN=OFF 
-DWITH_FFMPEG=ON -DWITH_GSTREAMER=OFF -DWITH_GTK=OFF -DWITH_IPP=OFF 
-DWITH_JASPER=ON -DWITH_JPEG=ON -DWITH_WEBP=ON -DWITH_OPENEXR=ON 
-DWITH_OPENGL=ON -DWITH_OPENNI=OFF -DWITH_OPENNI2=OFF -DWITH_PNG=ON 
-DWITH_PVAPI=OFF -DWITH_GIGEAPI=OFF -DWITH_QT=OFF -DWITH_QUICKTIME=OFF 
-DWITH_TBB=OFF -DWITH_OPENMP=OFF -DWITH_CSTRIPES=OFF -DWITH_PTHREADS_PF=OFF 
-DWITH_TIFF=ON -DWITH_UNICAP=OFF -DWITH_V4L=OFF -DWITH_LIBV4L=OFF 
-DWITH_XIMEA=OFF -DWITH_XINE=OFF -DWITH_CLP=OFF -DWITH_OPENCL=OFF 
-DWITH_OPENCL_SVM=OFF -DWITH_OPENCLAMDFFT=OFF -DWITH_OPENCLAMDBLAS=OFF 
-DWITH_INTELPERC=OFF -DWITH_IPP_A=OFF -DWITH_VA=OFF -DWITH_VA_INTEL=OFF 
-DWITH_GDAL=OFF -DWITH_GPHOTO2=OFF -DBUILD_SHARED_LIBS=ON 
-DBUILD_opencv_apps=ON -DBUILD_DOCS=OFF -DBUILD_EXAMPLES=OFF 
-DBUILD_PACKAGE=OFF -DBUILD_PERF_TESTS=OFF -DBUILD_TESTS=OFF 
-DBUILD_WITH_DYNAMIC_IPP=OFF -DBUILD_ZLIB=OFF -DBUILD_TIFF=OFF 
-DBUILD_JASPER=OFF -DBUILD_JPEG=OFF -DBUILD_PNG=OFF -DBUILD_OPENEXR=OFF 
-DBUILD_TBB=OFF -DPYTHON_EXECUTABLE=OFF -DBUILD_opencv_python2=OFF 
-DBUILD_opencv_python3=OFF -DINSTALL_C_EXAMPLES=OFF 
-DINSTALL_PYTHON_EXAMPLES=OFF -DENABLE_PRECOMPILED_HEADERS=ON -DENABLE_SSSE3=ON 
-DWITH_AVFOUNDATION=ON -DZLIB_LIBRARY=/opt/local/lib/libz.dylib 
-DBZIP2_LIBRARIES=/opt/local/lib/libbz2.dylib
opencv @3.1.0_5 (graphics, science)
Variants: avx, avx2, contrib, dc1394, debug, eigen, gdal, java, 
opencl, openni, python27, +python34, python35, qt4, qt5,
  tbb, universal, vtk

Description:  OpenCV is a library that is mainly aimed at real time 
computer vision. Some example areas would be
  Human-Computer Interaction (HCI), Object Identification, 
Segmentation and Recognition, Face Recognition,
  Gesture Recognition, Motion Tracking, Ego Motion, Motion 
Understanding, Structure From Motion (SFM), and
  Mobile Robotics.
Homepage: http://opencv.org

Extract Dependencies: unzip
Build Dependencies:   cmake, pkgconfig
Library Dependencies: zlib, bzip2, libpng, jpeg, jasper, tiff, webp, ilmbase, 
openexr, ffmpeg, python34, py34-numpy
Platforms:

Re: Criteria for picking compilers from fallback list ?

[Joshua Root]

On 2016-12-8 04:24 , Chris Jones wrote:

Hi,

I'm working on an update to the root6 port, where the minimum compiler
requirement has been increased in the latest release, such that I need
to update the compiler blacklist/fallback to force a macports compiler
to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).

This is all working OK, but I have noticed one thing I am trying to
understand is on 10.8 and 10.9 different fallbacks are being picked.

I have

compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
compiler.fallback-append macports-clang-3.9 macports-clang-3.8
macports-clang-3.7

On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
clang 3.8 is being used. I am curious as to what the logic is in the
blacklist portgroup that is leading to this different decisions to be
made ? I thought perhaps it was based on what clang ports where already
installed, but even after uninstalling all clang versions, the same
decisions are being made. Just curious...


The initial value of compiler.fallback differs based on cxx_stdlib 
because clang 3.5+ needs libc++. And yes, this will mean trouble for 
users on 10.8 who are using the default cxx_stdlib.


- Josh

Criteria for picking compilers from fallback list ?

[Chris Jones]

Hi,

I'm working on an update to the root6 port, where the minimum compiler 
requirement has been increased in the latest release, such that I need 
to update the compiler blacklist/fallback to force a macports compiler 
to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).


This is all working OK, but I have noticed one thing I am trying to 
understand is on 10.8 and 10.9 different fallbacks are being picked.


I have

compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3 
macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
compiler.fallback-append macports-clang-3.9 macports-clang-3.8 
macports-clang-3.7


On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9 
clang 3.8 is being used. I am curious as to what the logic is in the 
blacklist portgroup that is leading to this different decisions to be 
made ? I thought perhaps it was based on what clang ports where already 
installed, but even after uninstalling all clang versions, the same 
decisions are being made. Just curious...


cheers Chris

Re: declaring variants/subports in loops and loop variables

[Joshua Root]

On 2016-12-8 04:14 , René J.V. Bertin wrote:

On Wednesday December 07 2016 10:07:31 Ryan Schmidt wrote:

Hi,



The boost port shows a typical example of using "eval" and "subst" to ensure 
the variable values are substituted immediately.


In a nutshell, put the whole block where you want to force using the current 
values of all variables inside the curly braces of

eval [subst {}]

That seems to do the trick all right. I was a bit hoping for a `foreach` option 
to make limit the scope of the loop variable and all variables declared inside 
the loop, but that would probably be much more complicated to implement.

Is this the "strongly preferred" way or is it just as fine to use `if 
{[variant_isset xx]}` or `if {${subport} eq ...}`?


No, it's pretty much a terrible idea. Just don't use braces if you want 
substitution.


- Josh

Re: declaring variants/subports in loops and loop variables

[Brandon Allbery]

On Wed, Dec 7, 2016 at 5:14 PM, René J.V. Bertin 
wrote:

> That seems to do the trick all right. I was a bit hoping for a `foreach`
> option to make limit the scope of the loop variable and all variables
> declared inside the loop


Tcl doesn't grok closures, or scoping in general (although it does handle
some limited cases). It's just string manipulation. :/

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: declaring variants/subports in loops and loop variables

[René J . V . Bertin]

On Wednesday December 07 2016 10:07:31 Ryan Schmidt wrote:

Hi,


> The boost port shows a typical example of using "eval" and "subst" to ensure 
> the variable values are substituted immediately.

In a nutshell, put the whole block where you want to force using the current 
values of all variables inside the curly braces of

eval [subst {}]

That seems to do the trick all right. I was a bit hoping for a `foreach` option 
to make limit the scope of the loop variable and all variables declared inside 
the loop, but that would probably be much more complicated to implement.

Is this the "strongly preferred" way or is it just as fine to use `if 
{[variant_isset xx]}` or `if {${subport} eq ...}`?

R.

Re: declaring variants/subports in loops and loop variables

[Brandon Allbery]

On Wed, Dec 7, 2016 at 10:20 AM, René J.V. Bertin 
wrote:

> variant python${pv} description "Add bindings for Python ${pdv}" {
> depends_libs-append port:python${pv}
> # snip
> }
>

tcl tends to encourage you to think that { } is a block construct, and in
many languages that would close over the values of referenced variables.
It's not. It's a quoted string, and the expansion of $pdv and/or $pv will
be deferred until that quoted string is passed internally to tcl's eval. At
that point, any values for those variables must come from elsewhere.

Use a double quoted string and escape anything that needs it (but
specifically not those variables for which you need the current value).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: declaring variants/subports in loops and loop variables

[Ryan Schmidt]

> On Dec 7, 2016, at 11:04 AM, Joshua Root  wrote:
> 
> On 2016-12-8 03:07 , Ryan Schmidt wrote:
>> 
>>> On Dec 7, 2016, at 4:20 AM, René J.V. Bertin  wrote:
>>> 
>>> Hi,
>>> 
>>> See https://trac.macports.org/ticket/53022#comment:2
>>> 
>>> I'm still waiting for the final verdict from the ticket reporter, but it 
>>> seems that issue was one of those cases where I shouldn't have used a loop 
>>> variable in the declaration scope of a variant (nor subport):
>>> 
>>> {{{
>>> set pythonversions {3.4 3.5}
>>> foreach pdv ${pythonversions} {
>>>   set pv [join [lrange [split ${pdv} .] 0 1] ""]
>>>   # snip
>>>   variant python${pv} description "Add bindings for Python ${pdv}" {
>>>   depends_libs-append port:python${pv}
>>>   # snip
>>>   }
>>> }
>>> }}}
>>> 
>>> Why is it that this makes both the +python34 and +python35 variants depend 
>>> on the last value of ${pv}, and thus on port:python35? Are those 
>>> declaration scopes somehow evaluated outside of the loop? That hypothesis 
>>> is supported by the error that's raised when I unset pdv and pv immediately 
>>> after the loop.
> 
> This is almost exactly the same situation as:
> 
> foreach foo {bar baz} {
>   proc p_$foo {} {
>   puts $foo
>   }
> }
> p_bar
> p_baz
> 
> Try it in tclsh. (Variants are slightly different only in that they 
> automagically bring all global variables into scope. Thus you get pv with its 
> current value instead of a "no such variable" error.)
> 
>>> If so, is there a cleaner and not much more complex way to do loop-based 
>>> variant/subport declaration such that at least the loop variables are 
>>> undefined outside of the loop? Unsetting the variables works but isn't very 
>>> elegant and too easy to forget.
>>> 
>>> R.
>> 
>> The boost port shows a typical example of using "eval" and "subst" to ensure 
>> the variable values are substituted immediately.
> 
> That sounds overly complicated (there should be almost no reason to use eval, 
> ever.) Quotes instead of braces would allow variable substitution in the 
> variant body.

I agree, it sounds overly complicated to me too, but it is at least a block of 
code that has been tested by someone and added to many ports and seems to work.

Re: declaring variants/subports in loops and loop variables

[Joshua Root]

On 2016-12-8 03:07 , Ryan Schmidt wrote:



On Dec 7, 2016, at 4:20 AM, René J.V. Bertin  wrote:

Hi,

See https://trac.macports.org/ticket/53022#comment:2

I'm still waiting for the final verdict from the ticket reporter, but it seems 
that issue was one of those cases where I shouldn't have used a loop variable 
in the declaration scope of a variant (nor subport):

{{{
set pythonversions {3.4 3.5}
foreach pdv ${pythonversions} {
   set pv [join [lrange [split ${pdv} .] 0 1] ""]
   # snip
   variant python${pv} description "Add bindings for Python ${pdv}" {
   depends_libs-append port:python${pv}
   # snip
   }
}
}}}

Why is it that this makes both the +python34 and +python35 variants depend on 
the last value of ${pv}, and thus on port:python35? Are those declaration 
scopes somehow evaluated outside of the loop? That hypothesis is supported by 
the error that's raised when I unset pdv and pv immediately after the loop.


This is almost exactly the same situation as:

foreach foo {bar baz} {
proc p_$foo {} {
puts $foo
}
}
p_bar
p_baz

Try it in tclsh. (Variants are slightly different only in that they 
automagically bring all global variables into scope. Thus you get pv 
with its current value instead of a "no such variable" error.)



If so, is there a cleaner and not much more complex way to do loop-based 
variant/subport declaration such that at least the loop variables are undefined 
outside of the loop? Unsetting the variables works but isn't very elegant and 
too easy to forget.

R.


The boost port shows a typical example of using "eval" and "subst" to ensure 
the variable values are substituted immediately.


That sounds overly complicated (there should be almost no reason to use 
eval, ever.) Quotes instead of braces would allow variable substitution 
in the variant body.


- Josh

Re: `port edit`, local/console vs. remote use

[René J . V . Bertin]

On Wednesday December 7 2016 15:23:50 Brandon Allbery wrote:

>> VISUAL_EDITOR could be used instead of MP_GUI_EDITOR
>
>
>That name could be confusing considering that historically $VISUAL was a
>full screen CUI editor alternative to $EDITOR (that is, VISUAL=vi EDITOR=ed

Yes, sorry, I had misread VISUAL_EDITOR instead of VISUAL and EDITOR.

Regardless (and not to troll the list), I'm not sure if it's still very 
relevant to consider this ancient interpretation of "visual". How many people 
still use ed other than as a built-in vi component? Even people who do (or who 
maybe once did) should be aware that visual implies a bit more than what even 
vim has to offer, nowadays :)

R.

Re: `port edit`, local/console vs. remote use

[Brandon Allbery]

On Wed, Dec 7, 2016 at 9:26 AM, René J.V. Bertin 
wrote:

> VISUAL_EDITOR could be used instead of MP_GUI_EDITOR


That name could be confusing considering that historically $VISUAL was a
full screen CUI editor alternative to $EDITOR (that is, VISUAL=vi EDITOR=ed
...).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: `port edit`, local/console vs. remote use

[René J . V . Bertin]

On Wednesday December 7 2016 15:17:47 Rainer Müller wrote:

>> So the port__editor variable is never defined and the whole if could be 
>> removed?
>
>Of course it is defined. The variable is where proc parse_options stores
>the value of the --editor argument.

Right, my fault. I couldn't find any other occurrence of '_editor' in the port 
client and didn't think to check where the local_options array contents are set.

R.

Re: `port edit`, local/console vs. remote use

[Rainer Müller]

On 2016-12-07 14:30, René J.V. Bertin wrote:
> On Wednesday December 07 2016 14:15:26 Rainer Müller wrote:
> 
>> There used to be 'port ed' as an alias for 'port edit'. This was before
>> the unambiguous shortening of actions was introduced. This code in proc
>> action_portcmds was shared by both actions.
> 
> So the port__editor variable is never defined and the whole if could be 
> removed?

Of course it is defined. The variable is where proc parse_options stores
the value of the --editor argument.

Rainer

Re: `port edit`, local/console vs. remote use

[René J . V . Bertin]

On Wednesday December 07 2016 14:15:26 Rainer Müller wrote:

> There used to be 'port ed' as an alias for 'port edit'. This was before
> the unambiguous shortening of actions was introduced. This code in proc
> action_portcmds was shared by both actions.

So the port__editor variable is never defined and the whole if could be 
removed?

R

Re: `port edit`, local/console vs. remote use

[Rainer Müller]

On 2016-12-07 13:22, René J.V. Bertin wrote:
> My question about the weird port_${action}_editor variable still stands 
> though. What's that about?

There used to be 'port ed' as an alias for 'port edit'. This was before
the unambiguous shortening of actions was introduced. This code in proc
action_portcmds was shared by both actions.

Rainer

Re: `port edit`, local/console vs. remote use

[Rainer Müller]

On 2016-12-07 12:20, René J.V. Bertin wrote:
>> What does that achieve that setting $EDITOR doesn't?
> 
> For one thing it would also provide a convenient way to use a simple,
> lightweight editor when you want or have to avoid the usual editor
> for a few quick changes. The standard vi fallback also has certain
> power-user features that aren't always available in otherwise more
> convenient GUI editors. Evidently you can do `env EDITOR=foo port
> edit bar` or `vi `port file bar`` but 1) `port -f edit bar` is much
> quicker to type and 2) you have to remember the priorities among the
> 3 supported env. variables.

This is really not a problem of port(1). As said before, configure
MP_EDITOR, VISUAL or EDITOR according to your environment.

If you need to override the environment, port(1) already supports the
parameter 'port edit --editor ...' for that. You can already shorten
that to 'port ed --e ...'.

If you still need something shorter, think about a shell function or alias.

Rainer

Re: `port edit`, local/console vs. remote use

[René J . V . Bertin]

On Wednesday December 7 2016 11:36:20 Clemens Lang wrote:

>MacPorts should not be in the business of having a short option for everybody's
>favorite editor. We'd have -e for emacs, -t for textmate, -w for textwrangler,
>-d for ed(1), -s for sublime.

No, indeed, but that wasn't the gist of my suggestion. Personal choice would 
still be handled via an env. variable, the short option only serving to 
override it.

>We do not use short options after actions. Only global flags have short 
>options.

Even better: `port -f edit` would work just as well, and would probably 
equivalent to `port edit -f` if the edit procedure used 
`global_options(ports_force)`.

>From the looks of it we're talking about a small enough change: check for 
>[macports::global_option_isset ports_force] before doing the
{{{
if {[info exists local_options($editor_var)]} {} else {}
}}}

dance.

BTW, what's the intended use of the `local_options(ports_${action}_editor)` 
(where ${action} is always "edit" in this context)? This internal variable 
already overrides the env. variable, apparently without a way to change 
ports_${action}_editor from the commandline. IMHO that just makes it a bit more 
reasonable to check the ports_force setting.

>What does that achieve that setting $EDITOR doesn't?

For one thing it would also provide a convenient way to use a simple, 
lightweight editor when you want or have to avoid the usual editor for a few 
quick changes. The standard vi fallback also has certain power-user features 
that aren't always available in otherwise more convenient GUI editors. 
Evidently you can do `env EDITOR=foo port edit bar` or `vi `port file bar`` but 
1) `port -f edit bar` is much quicker to type and 2) you have to remember the 
priorities among the 3 supported env. variables.

R.

declaring variants/subports in loops and loop variables

[René J . V . Bertin]

Hi,

See https://trac.macports.org/ticket/53022#comment:2

I'm still waiting for the final verdict from the ticket reporter, but it seems 
that issue was one of those cases where I shouldn't have used a loop variable 
in the declaration scope of a variant (nor subport):

{{{
set pythonversions {3.4 3.5}
foreach pdv ${pythonversions} {
set pv [join [lrange [split ${pdv} .] 0 1] ""]
# snip
variant python${pv} description "Add bindings for Python ${pdv}" {
depends_libs-append port:python${pv}
# snip
}
}
}}}

Why is it that this makes both the +python34 and +python35 variants depend on 
the last value of ${pv}, and thus on port:python35? Are those declaration 
scopes somehow evaluated outside of the loop? That hypothesis is supported by 
the error that's raised when I unset pdv and pv immediately after the loop.

If so, is there a cleaner and not much more complex way to do loop-based 
variant/subport declaration such that at least the loop variables are undefined 
outside of the loop? Unsetting the variables works but isn't very elegant and 
too easy to forget. 

R.

Re: `port edit`, local/console vs. remote use

[René J . V . Bertin]

On Tuesday December 6 2016 11:41:39 Ryan Schmidt wrote:

>I haven't taken the time to look into how I could configure that. So instead, 
>I configure EDITOR to run TextWrangler, and whenever I ssh in and need to edit 
>a portfile, which is rare, I use 'vi $(port file someport)` instead of `port 
>edit someport`. 

I often use `port edit --editor XX foo` when I don't want to use the default 
editor. Maybe the cleanest solution would be to add a short option equivalent 
of `port edit --editor vi`. I'd say `port edit -v` as a mnemonic, but that 
could cause confusion with the verbose option. 

Either way this could serve users like Ryan and me:

- A new MP_GUI_EDITOR variable contains the name of the preferred/GUI editor 
that cannot be used over ssh
- `port edit` uses that value if available unless an option is given to 
override this choice
- nothing else changes

VISUAL_EDITOR could be used instead of MP_GUI_EDITOR but we don't know how many 
people use that variable.

A possible suitable choice for the short option: -f, as in "force editing even 
if your usual editor isn't available". In that case the option could override 
all env. variables with the possible exception of VISUAL_EDITOR if that's a 
traditional variable also used outside of MacPorts.

R