Re: [127391] trunk/dports/kde
Hi Nicolas, On 27/10/2014, at 3:02 PM, Nicolas Pavillon wrote: > On 27/10/2014 12:24, Ian Wadham wrote: >> Well, I just tried that and here is what happened… >> >> Tara:~>sudo port install palapeli +debug >> ---> Computing dependencies for palapeli >> ---> Fetching archive for palapeli >> ---> Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from >> http://packages.macports.org/palapeli >> ---> Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from >> http://jog.id.packages.macports.org/macports/packages/palapeli >> ---> Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from >> http://nue.de.packages.macports.org/macports/packages/palapeli >> ---> Fetching distfiles for palapeli >> ---> Attempting to fetch palapeli-4.13.3.tar.xz from >> http://mirror.internode.on.net/pub/kde/stable/4.13.3/src >> ---> Verifying checksums for palapeli >> ---> Extracting palapeli >> Error: org.macports.extract for port palapeli returned: >> >> ERROR: >> In order to install this port as +debug, >> Qt4 must also be installed with +debug. >> > This is a behaviour that is specific to the kde4 portgroup. More > specifically, it is specific to the qt4 portgroup, on which kde4 one depends > (see r73101). > > If you then say that this is not needed, it is the portgroup which should be > modified, not macports' behaviour. Well, yes, I agree. But portgroups are not my area of expertise, so I am relying on advice from you and Ryan here. The worst that can happen, FWICS, if you remove the requirement to install Qt4 with debug when anyone wants some KDE software with debug, is that, if they get a crash or want to use a debugger, the symbols will peter out if the problem was thrown up within the Qt4 library. It is quite normal for Qt4 to induce a crash, e.g. if one's KDE code marches past the end of a list or array. However, one can see where the KDE code was just before entering Qt and that and the Qt crash-message are enough information I reckon. OTOH, if you turn on debug in the Qt4 library, my understanding is that you will get flooded with loads of debug log-messages… for debugging Qt itself... I have never verified that, because KDE developer texts (on Linux) recommend that you NOT turn on debug in Qt4, so I have never (in 12 years) turned it on. If it will not break anything in MacPorts, let's remove the requirement for debug in Qt4. Then we will all be able to build debugging versions of KDE apps, libraries and utilities, to any required depth, using the principle Ryan has explained so well. That should be a lot of help with diagnosing KDE problems in MacPorts and Apple OS X, of which there are a few… ;-) And THEN there will be no need for René's "nostrip" variant, which is where this thread started out… :-) So what do you say, Nicolas? You're the man on this one. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127393] trunk/dports/lang/gcc46
On Oct 27, 2014, at 1:53 AM, Ryan Schmidt wrote: >> On Oct 27, 2014, at 12:38 AM, lar...@macports.org wrote: >> >> Revision >> 127393 >> Author >> lar...@macports.org >> Date >> 2014-10-26 22:38:40 -0700 (Sun, 26 Oct 2014) >> Log Message >> >> gcc46: Fix builds on Yosemite > > Thanks for doing these, Larry. No problem, although I'll probably be changing my tune as I get to the older GCCs :-/ >> Two birds with one stone: >> - Backport upstream's fixed OS version check (#43978). >> - Fix incorrect symbol lookup due to the Libtool >> MACOSX_DEPLOYMENT_TARGET bug (#44596 and #45483). > > Doesn't it need a revision increase, like was done for gcc47 and up? I don't think so because these problems only affect Yosemite, and gcc46 didn't build successfully on Yosemite until this revision. I revbumped gcc47 and up because they'd had the version checking fix applied before the symbol lookup fix, and in the interim Yosemite users could have ended up with broken installations. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127388] users/khindenburg/ports/kde/kdesrc-build/Portfile
> On Oct 26, 2014, at 3:27 PM, khindenb...@macports.org wrote:
>
> Revision
> 127388
> Author
> khindenb...@macports.org
> Date
> 2014-10-26 13:27:08 -0700 (Sun, 26 Oct 2014)
> Log Message
>
> kdesrc-build: do not use git commit as version; use cmake PortGroup; use
> perl_version for deps; change script perl to use macports
> Modified Paths
>
> • users/khindenburg/ports/kde/kdesrc-build/Portfile
> +post-configure {
> +reinplace "s|#!/usr/bin/env perl|#!${prefix}/bin/perl${perl_version}|g"
> ${worksrcpath}/${name}
> +reinplace "s|#!/usr/bin/env perl|#!${prefix}/bin/perl${perl_version}|g"
> ${worksrcpath}/kdesrc-build-setup
> +}
This is fine, but note that reinplace can take multiple filenames, and also
that it has a -W flag for specifying a working directory, so this can be
simplified to:
post-configure {
reinplace -W ${worksrcpath} "s|#!/usr/bin/env
perl|#!${prefix}/bin/perl${perl_version}|g" ${name} kdesrc-build-setup
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127393] trunk/dports/lang/gcc46
> On Oct 27, 2014, at 12:38 AM, lar...@macports.org wrote: > > Revision > 127393 > Author > lar...@macports.org > Date > 2014-10-26 22:38:40 -0700 (Sun, 26 Oct 2014) > Log Message > > gcc46: Fix builds on Yosemite Thanks for doing these, Larry. > Two birds with one stone: > - Backport upstream's fixed OS version check (#43978). > - Fix incorrect symbol lookup due to the Libtool > MACOSX_DEPLOYMENT_TARGET bug (#44596 and #45483). Doesn't it need a revision increase, like was done for gcc47 and up? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi again Ryan, On 27/10/2014, at 2:24 PM, Ian Wadham wrote: > On 27/10/2014, at 1:13 PM, Ryan Schmidt wrote: >> On Oct 26, 2014, at 9:03 PM, Ian Wadham wrote: >>> Variants in MacPorts are global in scope, which means that variants like >>> "debug" and >>> also "docs" get applied to *every* dependency, back as far as Sumerian clay >>> tablets… :-) >>> With KDE and Qt having such a long list of dependencies, well… >> >> Well, variants are passed on to *uninstalled* dependencies. If dependencies >> are already installed, they're not rebuilt with that variant. So if you >> don't want the variant passed down to uninstalled dependencies, install the >> dependencies first. For example, you could install the port normally first, >> without the debug variant, which would install all needed dependencies. Then >> you can reinstall the port with the +debug variant and only that port will >> be built with the debug variant. > > Well, I just tried that and here is what happened… > > Tara:~>sudo port install palapeli +debug > ---> Computing dependencies for palapeli > > Error: org.macports.extract for port palapeli returned: > > ERROR: > In order to install this port as +debug, > Qt4 must also be installed with +debug. But, to be fair, the following worked beautifully… :-) and exactly as you said, Ryan. It's the first time I have been able to see KDE doco on MacPorts in months… :-) Tara:~>sudo port clean palapeli ---> Cleaning palapeli Tara:~>sudo port install palapeli +docs ---> Computing dependencies for palapeli etc. So maybe there is a "poison pill" somewhere in the KDE or Qt portfiles which affects the +debug variant, but not +docs. It is certainly true that you CAN install KDE apps and libraries with debug options and without having debug in Qt. I do that almost every day in my KDE development environment, which uses git-repository versions of KDE, but links to qt4-mac in MacPorts, with no debug variant. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
On Oct 26, 2014, at 6:07 PM, Ryan Schmidt wrote:
>
>> On Oct 26, 2014, at 10:22 AM, Mark Brethen wrote:
>>
>>> On Oct 26, 2014, at 4:12 AM, Ryan Schmidt wrote:
>>>
On Oct 24, 2014, at 6:56 PM, Mark Brethen wrote:
I've found that compiling against macports libedit, which is configured
for wide-char/UTF-8 (--enable-widec option), breaks tab completion. The
program that I'm building is bundled with libedit and compiles it without
UTF-8 support. In this case tab completion works. Is it okay to install
this linked libedit library as part of the port?
>>>
>>> Sure, whatever works best for that program.
>>>
>>> The obvious concern would be: does that impeded the program's ability to
>>> process UTF-8 input?
>>
>> I think it uses the standard ASCII character set, but I'll check.
>
> Well libedit and libreadline are used in the process of acquiring user input.
> Can you guarantee that the user will only input ASCII characters? What
> happens if the user inputs other characters?
>
The basic characters which are used to build REDUCE symbols are the following:
• The 26 letters a through z
• The 10 decimal digits 0 through 9
• The special characters _ ! " $ % ' ( ) ⋆ + , - . / : ; < > = {
}⟨blank⟩
I'm not sure if it will let you enter anything other than above. I guess I
could test this.
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
On Oct 26, 2014, at 8:07 PM, Joshua Root wrote: > On 2014-10-25 10:56 , Mark Brethen wrote: >> I've found that compiling against macports libedit, which is configured for >> wide-char/UTF-8 (--enable-widec option), breaks tab completion. The program >> that I'm building is bundled with libedit and compiles it without UTF-8 >> support. In this case tab completion works. Is it okay to install this >> linked libedit library as part of the port? > > If this port and its dependents have compatible licenses, maybe you > could use readline instead? > > - Josh Can you do that without changing the developers code? I have made them aware that its not compatible with a UTF-8 terminal. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi Ryan, On 27/10/2014, at 1:13 PM, Ryan Schmidt wrote: > On Oct 26, 2014, at 9:03 PM, Ian Wadham wrote: >> On 27/10/2014, at 12:10 PM, Ryan Schmidt wrote: >>> On Oct 26, 2014, at 7:10 PM, Marko Käning wrote: >>> Ryan, any suggestions? >>> >>> My suggestions are: >>> >>> We try to avoid variant names beginning with "no". We try to use variant >>> names that >>> mention enabling something, rather than names that mention disabling >>> something. >> >> No problem with that… :-) >> >>> When there is a variant that aids in debugging a program, it is typically >>> named "debug". >> >> With all due respect, Ryan (and my respect for you is very great), please >> not this hoary >> old chestnut… :-) > > I didn't realize this topic was hoary or a chestnut! > > >> Variants in MacPorts are global in scope, which means that variants like >> "debug" and >> also "docs" get applied to *every* dependency, back as far as Sumerian clay >> tablets… :-) >> With KDE and Qt having such a long list of dependencies, well… > > Well, variants are passed on to *uninstalled* dependencies. If dependencies > are already installed, they're not rebuilt with that variant. So if you don't > want the variant passed down to uninstalled dependencies, install the > dependencies first. For example, you could install the port normally first, > without the debug variant, which would install all needed dependencies. Then > you can reinstall the port with the +debug variant and only that port will be > built with the debug variant. Well, I just tried that and here is what happened… Tara:~>sudo port install palapeli +debug ---> Computing dependencies for palapeli ---> Fetching archive for palapeli ---> Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://packages.macports.org/palapeli ---> Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/palapeli ---> Attempting to fetch palapeli-4.13.3_0+debug.darwin_11.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/palapeli ---> Fetching distfiles for palapeli ---> Attempting to fetch palapeli-4.13.3.tar.xz from http://mirror.internode.on.net/pub/kde/stable/4.13.3/src ---> Verifying checksums for palapeli ---> Extracting palapeli Error: org.macports.extract for port palapeli returned: ERROR: In order to install this port as +debug, Qt4 must also be installed with +debug. Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
On Oct 26, 2014, at 9:03 PM, Ian Wadham wrote: > On 27/10/2014, at 12:10 PM, Ryan Schmidt wrote: >> On Oct 26, 2014, at 7:10 PM, Marko Käning wrote: >> >>> Ryan, any suggestions? >> >> My suggestions are: >> >> We try to avoid variant names beginning with "no". We try to use variant >> names that >> mention enabling something, rather than names that mention disabling >> something. > > No problem with that… :-) > >> When there is a variant that aids in debugging a program, it is typically >> named "debug". > > With all due respect, Ryan (and my respect for you is very great), please not > this hoary > old chestnut… :-) I didn't realize this topic was hoary or a chestnut! > Variants in MacPorts are global in scope, which means that variants like > "debug" and > also "docs" get applied to *every* dependency, back as far as Sumerian clay > tablets… :-) > With KDE and Qt having such a long list of dependencies, well… Well, variants are passed on to *uninstalled* dependencies. If dependencies are already installed, they're not rebuilt with that variant. So if you don't want the variant passed down to uninstalled dependencies, install the dependencies first. For example, you could install the port normally first, without the debug variant, which would install all needed dependencies. Then you can reinstall the port with the +debug variant and only that port will be built with the debug variant. > If I ask for "debug" I get a huge build and vastly more code-symbols and > line-numbers > than I really want for debugging at the top of the dependency tree. Hence > René's idea > of "nostrip", which merely sets the linker not to throw away (strip) the > symbols in the KDE > part of the build. > > With "docs", I get docs OK, but again with a huge build and vastly more > documentation > tools than I will ever use (e.g. the whole of TeX and several language > translations), whereas > KDE only requires you to run meinproc4, which is part of KDE (but thereby > hangs another tale…). > >> If the existing debug variant in the portgroup is not useful, perhaps we >> need to reconsider that variant. > > Yes!!! > > I have canvassed that once or twice on this list and there has been useful and > informed discussion, but so far no action… :-( > > I think all this needs is to make "debug" and "docs" exceptional variants in > MacPorts, in > that they are treated as applying only to the currently requested port and > not to all of its > dependencies… It's probably not a good idea to have different base behavior for different variants based solely on their names. That's just confusing. > Maybe, too, "+docs" should be the default for top-level ports, but not for > all the libraries > and utilities they depend upon --- if we can separate the sheep from the > goats… :-) It would be better to have *-docs subports, rather than +docs variants. That way users can install or uninstall the *-docs subports at will. For some ports' build systems however this is not easy to do. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi Ryan, On 27/10/2014, at 12:10 PM, Ryan Schmidt wrote: > On Oct 26, 2014, at 7:10 PM, Marko Käning wrote: > >> Ryan, any suggestions? > > My suggestions are: > > We try to avoid variant names beginning with "no". We try to use variant > names that > mention enabling something, rather than names that mention disabling > something. No problem with that… :-) > When there is a variant that aids in debugging a program, it is typically > named "debug". With all due respect, Ryan (and my respect for you is very great), please not this hoary old chestnut… :-) Variants in MacPorts are global in scope, which means that variants like "debug" and also "docs" get applied to *every* dependency, back as far as Sumerian clay tablets… :-) With KDE and Qt having such a long list of dependencies, well… If I ask for "debug" I get a huge build and vastly more code-symbols and line-numbers than I really want for debugging at the top of the dependency tree. Hence René's idea of "nostrip", which merely sets the linker not to throw away (strip) the symbols in the KDE part of the build. With "docs", I get docs OK, but again with a huge build and vastly more documentation tools than I will ever use (e.g. the whole of TeX and several language translations), whereas KDE only requires you to run meinproc4, which is part of KDE (but thereby hangs another tale…). > If the existing debug variant in the portgroup is not useful, perhaps we need > to reconsider that variant. Yes!!! I have canvassed that once or twice on this list and there has been useful and informed discussion, but so far no action… :-( I think all this needs is to make "debug" and "docs" exceptional variants in MacPorts, in that they are treated as applying only to the currently requested port and not to all of its dependencies… Maybe, too, "+docs" should be the default for top-level ports, but not for all the libraries and utilities they depend upon --- if we can separate the sheep from the goats… :-) All the best, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
On Oct 26, 2014, at 7:10 PM, Marko Käning wrote: > Ryan, any suggestions? My suggestions are: We try to avoid variant names beginning with "no". We try to use variant names that mention enabling something, rather than names that mention disabling something. When there is a variant that aids in debugging a program, it is typically named "debug". If the existing debug variant in the portgroup is not useful, perhaps we need to reconsider that variant. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
On 2014-10-25 10:56 , Mark Brethen wrote: > I've found that compiling against macports libedit, which is configured for > wide-char/UTF-8 (--enable-widec option), breaks tab completion. The program > that I'm building is bundled with libedit and compiles it without UTF-8 > support. In this case tab completion works. Is it okay to install this linked > libedit library as part of the port? If this port and its dependents have compatible licenses, maybe you could use readline instead? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi René and Ryan, On 27 Oct 2014, at 01:04 , René J.V. Bertin wrote: > I've started calling the variant +devel since that discussion. But AFAIC it > doesn't need to be included in an official port … ok, removing this variant might be a way to go… >> there is a “debug” variant already available due to the kde portgroup... >> Why did you need to introduce a “nostrip” variant? Is that because of >> CMAKE_STRIP:FILEPATH? > > The KDE +debug variant requires qt4-mac +debug, and that's a sort of > frankenmonster I'd prefer to avoid. I see what you mean, of course. :) > It's basically useless, most importantly because AFAIK it doesn't allow > post-mortem debugging. > My variant builds with RelWithDebInfo (as opposed to Release used by normal > MacPorts builds) and takes an extra step to prevent that debug info from > being stripped. I've never been very good with names, so called it +nostrip. Hmm, ok. This is a discussion we started a while ago on MacPorts-devel, but introducing a dedicated debug-kde variant never took off... Ryan, any suggestions? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
Hi René,
On 27 Oct 2014, at 00:34 , Ryan Schmidt wrote:
>
>> On Oct 26, 2014, at 6:24 PM, m...@macports.org wrote:
>>
>> Revision
>> 127391
>> Author
>> m...@macports.org
>> Date
>> 2014-10-26 16:24:49 -0700 (Sun, 26 Oct 2014)
>> Log Message
>>
>> kde4-workspace: new port (closes René's ticket #44236)
>
>> Added: trunk/dports/kde/kde4-workspace/Portfile (0 => 127391)
>
>> +variant nostrip description {Prevent stripping of binaries} {
>> +configure.args-delete -DCMAKE_BUILD_TYPE=Release
>> +configure.args-append -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
>> -DCMAKE_STRIP:FILEPATH=/bin/echo
>> +}
>
> Would it make sense to name this variant "debug" instead? It would be nice to
> avoid variants whose names begin with "no”.
there is a “debug” variant already available due to the kde portgroup...
Why did you need to introduce a “nostrip” variant? Is that because of
CMAKE_STRIP:FILEPATH?
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [127391] trunk/dports/kde
> On Oct 26, 2014, at 6:24 PM, m...@macports.org wrote:
>
> Revision
> 127391
> Author
> m...@macports.org
> Date
> 2014-10-26 16:24:49 -0700 (Sun, 26 Oct 2014)
> Log Message
>
> kde4-workspace: new port (closes René's ticket #44236)
> Added: trunk/dports/kde/kde4-workspace/Portfile (0 => 127391)
> +variant nostrip description {Prevent stripping of binaries} {
> + configure.args-delete -DCMAKE_BUILD_TYPE=Release
> + configure.args-append -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
> -DCMAKE_STRIP:FILEPATH=/bin/echo
> +}
Would it make sense to name this variant "debug" instead? It would be nice to
avoid variants whose names begin with "no".
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
> On Oct 26, 2014, at 10:22 AM, Mark Brethen wrote: > >> On Oct 26, 2014, at 4:12 AM, Ryan Schmidt wrote: >> >>> On Oct 24, 2014, at 6:56 PM, Mark Brethen wrote: >>> >>> I've found that compiling against macports libedit, which is configured for >>> wide-char/UTF-8 (--enable-widec option), breaks tab completion. The program >>> that I'm building is bundled with libedit and compiles it without UTF-8 >>> support. In this case tab completion works. Is it okay to install this >>> linked libedit library as part of the port? >> >> Sure, whatever works best for that program. >> >> The obvious concern would be: does that impeded the program's ability to >> process UTF-8 input? > > I think it uses the standard ASCII character set, but I'll check. Well libedit and libreadline are used in the process of acquiring user input. Can you guarantee that the user will only input ASCII characters? What happens if the user inputs other characters? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
On Oct 26, 2014, at 5:12 AM, Ryan Schmidt wrote: > On Oct 24, 2014, at 6:56 PM, Mark Brethen wrote: > >> I've found that compiling against macports libedit, which is configured for >> wide-char/UTF-8 (--enable-widec option), breaks tab completion. The program >> that I'm building is bundled with libedit and compiles it without UTF-8 >> support. In this case tab completion works. Is it okay to install this >> linked libedit library as part of the port? > > Sure, whatever works best for that program. Make sure you don't install it in a location where it'll be found by other builds. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
I think it uses the standard ASCII character set, but I'll check. Sent from my iPhone > On Oct 26, 2014, at 4:12 AM, Ryan Schmidt wrote: > > >> On Oct 24, 2014, at 6:56 PM, Mark Brethen wrote: >> >> I've found that compiling against macports libedit, which is configured for >> wide-char/UTF-8 (--enable-widec option), breaks tab completion. The program >> that I'm building is bundled with libedit and compiles it without UTF-8 >> support. In this case tab completion works. Is it okay to install this >> linked libedit library as part of the port? > > Sure, whatever works best for that program. > > The obvious concern would be: does that impeded the program's ability to > process UTF-8 input? > > ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: lib edit --enable-widec option breaks tab-completion
On Oct 24, 2014, at 6:56 PM, Mark Brethen wrote: > I've found that compiling against macports libedit, which is configured for > wide-char/UTF-8 (--enable-widec option), breaks tab completion. The program > that I'm building is bundled with libedit and compiles it without UTF-8 > support. In this case tab completion works. Is it okay to install this linked > libedit library as part of the port? Sure, whatever works best for that program. The obvious concern would be: does that impeded the program's ability to process UTF-8 input? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
