Re: upgrading MacPorts after updating from 10.6 to 10.9 - missing gnutar?
I'm continuing my endeavours after a little break ...
The source install I'm upgrading for 10.9 had 2 perl5 variants installed:
perl5 @5.12.4_0+perl5_12
perl5 @5.12.4_0+perl5_16 (active)
both presumably dependencies of ports I requested, and their upgrades over the
time (I'm running 10.6 with MacPorts since autumn 2010). I also have a whole
slew (55) of p5.12-* ports, and a few p5.16-* ports.
It looks like having those 2 variants may be causing reinstallation issues, as
I've seen many a message referring to @perl5_12 when apparently a port didn't
request a specific perl5 variant, and failures on the installation of all p5.12
ports.
(Example extract from one of the build logs:
:notice:configure --- Configuring p5.12-error
:debug:configure Using compiler 'Xcode Clang'
:debug:configure Executing org.macports.configure (p5.12-error)
:debug:configure Environment: CPATH='/Volumes/Debian/MacPorts/include'
CFLAGS='-Os' CPPFLAGS='-I/Volumes/Debian/MacPorts/include' CXXFLAGS='-Os'
LIBRARY_PATH='/Volumes/Debian/MacPorts/lib' MACOSX_DEPLOYMENT_TARGET='10.9'
CXX='/usr/bin/clang++'
CC_PRINT_OPTIONS_FILE='/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_perl_p5-error/p5.12-error/work/.CC_PRINT_OPTIONS'
F90FLAGS='-Os' LDFLAGS='-L/Volumes/Debian/MacPorts/lib
-Wl,-headerpad_max_install_names' FCFLAGS='-Os' OBJC='/usr/bin/clang'
OBJCXX='/usr/bin/clang++' INSTALL='/usr/bin/install -c'
PERL_AUTOINSTALL='--skipdeps' FFLAGS='-Os' OBJCFLAGS='-Os' OBJCXXFLAGS='-Os'
CC_PRINT_OPTIONS='YES' CC='/usr/bin/clang'
:debug:configure Assembled command: 'cd
/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_perl_p5-error/p5.12-error/work/Error-0.17016
/Volumes/Debian/MacPorts/bin/perl5.12 Makefile.PL INSTALLDIRS=vendor
CC=/usr/bin/clang LD=/usr/bin/clang'
:debug:configure Executing command line: cd
/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_perl_p5-error/p5.12-error/work/Error-0.17016
/Volumes/Debian/MacPorts/bin/perl5.12 Makefile.PL INSTALLDIRS=vendor
CC=/usr/bin/clang LD=/usr/bin/clang
:info:configure Checking if your kit is complete...
:info:configure Looks good
:info:configure CPAN::Meta::YAML 0.002 is not available
:info:configure at
/Volumes/Debian/MacPorts/lib/perl5/site_perl/5.12.4/CPAN/Meta.pm line 320.
:info:configure Command failed: cd
/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_perl_p5-error/p5.12-error/work/Error-0.17016
/Volumes/Debian/MacPorts/bin/perl5.12 Makefile.PL INSTALLDIRS=vendor
CC=/usr/bin/clang LD=/usr/bin/clang
:info:configure Exit code: 2
:error:configure org.macports.configure for port p5.12-error returned:
configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
while executing
$procedure $targetname
:info:configure Warning: targets not executed for p5.12-error:
org.macports.activate org.macports.configure org.macports.build
org.macports.destroot org.macports.install
:error:configure Failed to install p5.12-error
:debug:configure Registry error: p5.12-net-ssleay not registered as installed
active.
invoked from within
registry_active ${subport}
invoked from within
$workername eval registry_active \${subport}
:notice:configure Please see the log file for port p5.12-error for details:
/Volumes/Debian/MacPorts/var/macports/logs/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_perl_p5-error/p5.12-error/main.log
)
I hope I haven't overlooked anything in the docs, but how does the restore.tcl
script handle multiple perl5 variants/versions? Given that I do not myself have
any direct requirements on perl versions, shouldn't I just have removed all
references to specific perl5 versions/variants, or bumped all +perl5_12 to
+perl5_16? If so, can I rectify that WITHOUT having to start everything from
scratch?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: questions about writing Portfile
Hi, yeah, that's what I decided to do but sometimes, it mixed between install/build between both repository. still, not too annoying. Make sure you run portindex in your local repository after you've added new ports, or MacPorts will not find them and use those from the main tree. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
Hi, I'm getting a build error installing the +asm+universal x264 variant (x264@20130823+asm+universal) on OS X 10.9.1: :info:build ./common/x86/util.h:131:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build ./common/x86/util.h:194:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build 2 errors generated. From what I remember these occur because clang's heuristic doesn't necessarily find a possible solution (remember register allocation is a complex problem); GCC's algorithms try harder and eventually succeed. Most of these problems were considered to be caused by upstream and the solution was to remove some constraints for the inline assembler. with /usr/bin/clang being Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix Building with configure.compiler=macports-gcc-4.7 succeeds fine. Is this a bug I should report? Yes, this is a bug you should report. Maybe updating the port to a more recent version would fix the problem. (Or should I make an official suggestion to use gcc everywhere where Apple-specific options aren't required as long as clang isn't completely ready to be the main compiler on linux? ;) ) Due to the whole C++ libc++ situation, this is not going to happen. Clang will be our main compiler suite, and switching now and getting the bugs that still exist fixed is the correct thing to do. Clang is not going away, but GCC on OS X already has. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
On Mar 01, 2014, at 15:55, Clemens Lang wrote: Building with configure.compiler=macports-gcc-4.7 succeeds fine. Is this a bug I should report? Yes, this is a bug you should report. Maybe updating the port to a more recent version would fix the problem. 20130823 is the latest version, from what I can see. (Or should I make an official suggestion to use gcc everywhere where Apple-specific options aren't required as long as clang isn't completely ready to be the main compiler on linux? ;) ) Due to the whole C++ libc++ situation, this is not going to happen. Clang will be our main compiler suite, and switching now and getting the bugs that still exist fixed is the correct thing to do. Clang is not going away, but GCC on OS X already has. I don't know what whole C++ libc++ situation you're referring to, I was just thinking that a large majority of the available ports are (or seem to be) things developed for Linux, and as such using the Linux default compiler would probably facilitate matters (cf. Gentoo Prefix). OTOH, I have never managed yet to get even gcc-4.8 to build with -march=native on my Core i7 CPU (or maybe I should say to get it to emit code that the linker could handle). But I see your point. Too bad Apple chose a compiler that may be much faster and have nice analysis but has yet to beat gcc on any of my tests involving lengthy (computing) operations ... ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
On Sat, Mar 1, 2014 at 10:26 AM, René J.V. Bertin rjvber...@gmail.comwrote: (Or should I make an official suggestion to use gcc everywhere where Apple-specific options aren't required as long as clang isn't completely ready to be the main compiler on linux? ;) ) Due to the whole C++ libc++ situation, this is not going to happen. Clang will be our main compiler suite, and switching now and getting the bugs that still exist fixed is the correct thing to do. Clang is not going away, but GCC on OS X already has. I don't know what whole C++ libc++ situation you're referring to, I was just thinking that a large majority of the available ports are (or seem to be) things developed for Linux, and as such using the Linux default compiler would probably facilitate matters (cf. Gentoo Prefix). OTOH, I have Anything that touches or might ever be used by C++ has to use clang's C++ runtime, not gcc's. This is because Apple switched all the system libraries to clang. (It's a bit more complex than that, look in the FAQ for something closer to the real story. http://trac.macports.org/wiki/FAQ#libcpp) Your suggestion would work fine on Linux where gcc's C++ runtime is the standard one (and Linux isn't allergic to GPL3 like Apple is, so it can use a newer libstdc++ that is compatible with clang's libc++), but Apple sets the rules here by what it does with system/Xcode provided libraries, and the MacPorts team has already spent too much time failing to find ways to make gcc's runtime coexist with clang's. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
On Mar 01, 2014, at 16:36, Brandon Allbery wrote: Anything that touches or might ever be used by C++ has to use clang's C++ runtime, not gcc's. This is because Apple switched all the system libraries to clang. (It's a bit more complex than that, look in the FAQ for something closer to the real story. http://trac.macports.org/wiki/FAQ#libcpp) That seems to apply more to using more recent LLVM/Clang on 10.8 and earlier (is clang-3.3 more recent or older?) than on using recent gcc versions on 10.9 ... but it looks like the real bottleneck is not the copyright flavour but binary (in)compatibility between regular (old?) C++ and C++11. I can't remember having looked at how much of C++11 GCC supports, but if it does (or is planned), wouldn't its libc++ follow? Your suggestion would work fine on Linux where gcc's C++ runtime is the standard one (and Linux isn't allergic to GPL3 like Apple is, so it can use a newer libstdc++ that is compatible with clang's libc++), but Apple sets the rules here by what it does with system/Xcode provided libraries, and the MacPorts team has already spent too much time failing to find ways to make gcc's runtime coexist with clang's. That I can understand, but what exactly does it mean for using gcc in one's own projects? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
On Sat, Mar 1, 2014 at 11:02 AM, René J.V. Bertin rjvber...@gmail.comwrote: On Mar 01, 2014, at 16:36, Brandon Allbery wrote: That seems to apply more to using more recent LLVM/Clang on 10.8 and earlier (is clang-3.3 more recent or older?) than on using recent gcc versions on 10.9 ... but it looks like the real bottleneck is not the copyright flavour but binary (in)compatibility between regular (old?) C++ The copyright comes in because the compatible libstdc++ is GPL3 so Apple refuses to ship or support it. That I can understand, but what exactly does it mean for using gcc in one's own projects? Use with care, don't expect C++ stuff built with g++ to work with Apple's libraries. (gcc later than 4.2 uses the license-incompatible libstdc++, which is why Apple froze gcc at 4.2 in xcode for so long.) C-only stuff is probably okay. But you can't generally get away with using gcc for C and clang++ for C++ in a mixed language project, and there isn't that much out there in C++ that doesn't have some C glue somewhere because most libraries are in C. I'm not up on the full extent of the incompatibility, but there are a lot of bug reports resulting from attempting to mix g++ compiled stuff with Apple libraries with Xcode 5 so apparently there are more than just license issues involved. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
Hi, On Mar 01, 2014, at 17:29, Clemens Lang wrote: Frankly, for my own stuff (which never gets beyond my own machines in binary form) I couldn't care less about copyright issues, I don't understand the concept of different flavours of free ;) with 10.9. So if you're writing C++ code for OS X, you'll have to use clang++ -stdlib=libc++ as soon as you link against a single other C++ library or export a C++ interface. For now apps using X11 seem fine, but I haven't tried much yet. Btw, on getting GCC use your Core i7 capabilities: That will probably not happen either, because the GNU as shipped by Apple doesn't support AVX instructions – clang is currently the only compiler able to use AVX instructions on OS X. Wasn't counting on it anyway. So in general, GCC is pretty much dead on newer versions of OS X and you should really have very very very good reasons to attempt to use anything but clang. Performance is such a reason in my book, as I said, in just about any test I've done clang-generated code performs consistently (and sometimes probably significantly) worse than gcc-generated code does. I don't know to what extent clang does auto-vectorisation, but I've been impressed by the progress made in that domain by gcc (I've already seen an auto-vectorised version of a scalar video format conversion function from Perian outperform the hand-coded SSE2 version by almost a factor 10). Fortunately we're no longer living in times where a few percents in performance gain or loss were actually noticeable in common use scenarios! I also find gcc's error messages to be much more readable (though less so in the more recent versions). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
Hi, Performance is such a reason in my book, as I said, in just about any test I've done clang-generated code performs consistently (and sometimes probably significantly) worse than gcc-generated code does. I don't know to what extent clang does auto-vectorisation, but I've been impressed by the progress made in that domain by gcc (I've already seen an auto-vectorised version of a scalar video format conversion function from Perian outperform the hand-coded SSE2 version by almost a factor 10). Fortunately we're no longer living in times where a few percents in performance gain or loss were actually noticeable in common use scenarios! I also find gcc's error messages to be much more readable (though less so in the more recent versions). What clang and gcc versions have you compared ? Without these, any comparison is meaningless. Fwiw, in my tests gcc 4.8 and clang 3.4 are very similar. Cannot agree with you on the compiler messages though. Clang's are just more useful, as far as i am concerned.. The bottom line though is this is all irrelevant. You simply cannot reliably use gcc (or to be more precise libstdc++), on os x 10.9 onwards, without most likely running into problems. This ship has sailed and no amount of arguments as to why gcc is better is going to change anything. Chris ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
On 3/1/14 6:48 AM, René J.V. Bertin wrote: I'm getting a build error installing the +asm+universal x264 variant (x264@20130823+asm+universal) on OS X 10.9.1: :info:build /usr/bin/clang -Wshadow -O3 -ffast-math -m32 -I. -fno-common -read_only_relocs suppress -arch i386 -Wall -I. -I. -falign-loops=16 -march=i686 -mfpmath=sse -msse -std=gnu99 -mpreferred-stack-boundary=5 -fPIC -fomit-frame-pointer -fno-tree-vectorize -c -o encoder/me.o encoder/me.c :info:build clang: warning: argument unused during compilation: '-read_only_relocs suppress' :info:build clang: warning: argument unused during compilation: '-falign-loops=16' :info:build clang: warning: argument unused during compilation: '-mfpmath=sse' :info:build clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=5' :info:build In file included from encoder/me.c:28: :info:build In file included from ./common/common.h:987: :info:build ./common/x86/util.h:131:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build ./common/x86/util.h:194:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build 2 errors generated. with /usr/bin/clang being Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix Building with configure.compiler=macports-gcc-4.7 succeeds fine. Is this a bug I should report? (Or should I make an official suggestion to use gcc everywhere where Apple-specific options aren't required as long as clang isn't completely ready to be the main compiler on linux? ;) ) Although this thread has turned into more of a clang++ discussion, I'll just mention to that I am currently upgrading x264 to a more recent version as part of upgrading ffmpeg to version 2.1.4 and will look into this issue as part of that up upgrade. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
At 12:13 PM -0800 3/1/14, David Evans wrote: On 3/1/14 6:48 AM, René J.V. Bertin wrote: I'm getting a build error installing the +asm+universal x264 variant (x264@20130823+asm+universal) on OS X 10.9.1: :info:build /usr/bin/clang -Wshadow -O3 -ffast-math -m32 -I. -fno-common -read_only_relocs suppress -arch i386 -Wall -I. -I. -falign-loops=16 -march=i686 -mfpmath=sse -msse -std=gnu99 -mpreferred-stack-boundary=5 -fPIC -fomit-frame-pointer -fno-tree-vectorize -c -o encoder/me.o encoder/me.c :info:build clang: warning: argument unused during compilation: '-read_only_relocs suppress' :info:build clang: warning: argument unused during compilation: '-falign-loops=16' :info:build clang: warning: argument unused during compilation: '-mfpmath=sse' :info:build clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=5' :info:build In file included from encoder/me.c:28: :info:build In file included from ./common/common.h:987: :info:build ./common/x86/util.h:131:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build ./common/x86/util.h:194:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build 2 errors generated. with /usr/bin/clang being Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix Building with configure.compiler=macports-gcc-4.7 succeeds fine. Is this a bug I should report? (Or should I make an official suggestion to use gcc everywhere where Apple-specific options aren't required as long as clang isn't completely ready to be the main compiler on linux? ;) ) Although this thread has turned into more of a clang++ discussion, I'll just mention to that I am currently upgrading x264 to a more recent version as part of upgrading ffmpeg to version 2.1.4 and will look into this issue as part of that up upgrade. While looking at some other stuff, I noticed that libvpx to 1.3.0 (we currently have 1.2.0) apparently including the VP9 codec. http://blog.webmproject.org/2013/07/vp9-lands-in-chrome-dev-channel.html Would you consider looking at upgrading libvpx, as well? Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: build error x264 on OS X 10.9.1
On 3/1/14 1:23 PM, Craig Treleaven wrote: At 12:13 PM -0800 3/1/14, David Evans wrote: On 3/1/14 6:48 AM, René J.V. Bertin wrote: I'm getting a build error installing the +asm+universal x264 variant (x264@20130823+asm+universal) on OS X 10.9.1: :info:build /usr/bin/clang -Wshadow -O3 -ffast-math -m32 -I. -fno-common -read_only_relocs suppress -arch i386 -Wall -I. -I. -falign-loops=16 -march=i686 -mfpmath=sse -msse -std=gnu99 -mpreferred-stack-boundary=5 -fPIC -fomit-frame-pointer -fno-tree-vectorize -c -o encoder/me.o encoder/me.c :info:build clang: warning: argument unused during compilation: '-read_only_relocs suppress' :info:build clang: warning: argument unused during compilation: '-falign-loops=16' :info:build clang: warning: argument unused during compilation: '-mfpmath=sse' :info:build clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=5' :info:build In file included from encoder/me.c:28: :info:build In file included from ./common/common.h:987: :info:build ./common/x86/util.h:131:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build ./common/x86/util.h:194:9: error: ran out of registers during register allocation :info:build movq (%2), %%mm5 \n :info:build ^ :info:build 2 errors generated. with /usr/bin/clang being Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix Building with configure.compiler=macports-gcc-4.7 succeeds fine. Is this a bug I should report? (Or should I make an official suggestion to use gcc everywhere where Apple-specific options aren't required as long as clang isn't completely ready to be the main compiler on linux? ;) ) Although this thread has turned into more of a clang++ discussion, I'll just mention to that I am currently upgrading x264 to a more recent version as part of upgrading ffmpeg to version 2.1.4 and will look into this issue as part of that up upgrade. While looking at some other stuff, I noticed that libvpx to 1.3.0 (we currently have 1.2.0) apparently including the VP9 codec. http://blog.webmproject.org/2013/07/vp9-lands-in-chrome-dev-channel.html Would you consider looking at upgrading libvpx, as well? Craig Yes, thanks for mentioning it. Dave ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: upgrading MacPorts after updating from 10.6 to 10.9 - missing gnutar?
On Mar 1, 2014, at 06:48, René J.V. Bertin rjvber...@gmail.com wrote: Given that I do not myself have any direct requirements on perl versions, shouldn't I just have removed all references to specific perl5 versions/variants, or bumped all +perl5_12 to +perl5_16? I recommend that. If so, can I rectify that WITHOUT having to start everything from scratch? I’d try “sudo port uninstall installed and name:^p5.12”. If nothing depends on them, that should succeed. If that fails, it’ll tell you what port requires it. You can then investigate whether that port offers variants for newer versions of perl. Since it was only recently that the default perl was changed from 5.12 to 5.16, there are probably still many ports that depend unconditionally on 5.12 and have yet to be updated to 5.16. If you find such ports, please file tickets. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gnome-terminal again
On Sat, Mar 1, 2014 at 8:39 PM, James Linder j...@tigger.ws wrote: The macport gnome-terminal suffers from similar active and inactive tabs http://askubuntu.com/questions/40332/how-to-make-selected-tab-in-terminal-more-prominent dconf has nothing that looks helpful and the suggestions in the above don’t do anything. Theming on OS X tends to be weird, because Apple early on threatened legal action against anyone trying to replicate Aqua in e.g. themes and the backlash included disabling all theming on OS X. (Qt/KDE still refuses to do any theming on OS X; I don't know if Gtk+/Gnome still does.) Alternately has anyone a suggestion for a decent multi tab terminal, please I’m all ears. I spend 90% of my time in the terminal - it is important. I use iTerm 2, which is the iTerm2 port in MacPorts or available as a standalone dmg. (Note that there is also an iTerm port, which is an older version which was desupported several years ago. iTerm 2 is enhanced from the same codebase but with active maintainers after the original authors dropped it.) In general it's much better than Apple's Terminal. That said, I still don't run Mavericks much --- one small machine which is a bit slow anyway, so I can't really judge speed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gnome-terminal again
On 3/1/14 5:39 PM, James Linder wrote: G’day All The macport gnome-terminal suffers from similar active and inactive tabs http://askubuntu.com/questions/40332/how-to-make-selected-tab-in-terminal-more-prominent dconf has nothing that looks helpful and the suggestions in the above don’t do anything. Before I wade into the src code, has anybody solved the issue? Alternately has anyone a suggestion for a decent multi tab terminal, please I’m all ears. I spend 90% of my time in the terminal - it is important. I mostly rejected the regular utility/term because cursor movement was sluggish, but and maybe it was rose coloured memories frm snowleopard, gnome-terminal (mavericks) is just as sluggish now. Has mavericks done that? Thanks James ___ GNOME apps like gnome-terminal support theming but only if building for X11 not Quartz. However, for this to work correctly gnome-settings-daemon needs to be running (since theming is a desktop wide issue rather than an application one). This normally happens when a GNOME session is started but if you only want to run specific applications (more common on MacPorts) then you can start it by hand by executing /opt/local/libexec/gnome-settings-daemon --replace which will then run as long as you are logged in. Ignore the various startup messages on the console. In the case of gnome-terminal, this will make the difference between all tabs looking identical and the active tab being clearly highlighted (with a blue accent at the top using the default theme). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
