Re: Quick question: how to "clear" earlier variants list?
On Thu, Sep 17, 2015 at 12:40 PM, Kennedy, Smith (Wireless Architect) < smith.kenn...@hp.com> wrote: > I've been struggling with getting Wireshark 1.12.7 to build lately - there > seems to be some issue with the Lua bindings. I tried to disable the Lua > bindings in the build, but the set of variants I had previously set seem to > be "sticky", even after I do a "sudo port clean --all wireshark". What > else do I need to do to clear out the previously set of variants? > Use - instead of + on each variant you want to remove. Not sure but I think --enforce-variants with no variants named would get you the default? -- 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
Quick question: how to "clear" earlier variants list?
Hello, I've been struggling with getting Wireshark 1.12.7 to build lately - there seems to be some issue with the Lua bindings. I tried to disable the Lua bindings in the build, but the set of variants I had previously set seem to be "sticky", even after I do a "sudo port clean --all wireshark". What else do I need to do to clear out the previously set of variants? (And, anybody having issues building Wireshark 1.12.7?) Cheers, Smith ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Quick question: how to "clear" earlier variants list?
Thanks. I understand why they are sticky, I'm just fighting with the Wireshark port and need it to build... I ended up wiping out all of /opt and reinstalling MacPorts 2.3.3 to try from scratch. And now I also just blew up my build environment by installing Xcode 7...and there is no OS X 10.10 SDK... Smith > On 2015-09-17, at 11:18 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > > > On Sep 17, 2015, at 11:40 AM, Kennedy, Smith wrote: > >> I've been struggling with getting Wireshark 1.12.7 to build lately - there >> seems to be some issue with the Lua bindings. I tried to disable the Lua >> bindings in the build, but the set of variants I had previously set seem to >> be "sticky", even after I do a "sudo port clean --all wireshark". What else >> do I need to do to clear out the previously set of variants? > > Variants are intended to be sticky to the extent that if you install a port > with a particular set of variants, that set of variants will be preserved > when you later upgrade the port. If you don't want that, install (not > upgrade) the port, with the set of variants you want. > > Variants are also intended to be sticky to the extent that if you list some > variants in the variants.conf file, that list of variants will be used for > any port you install thereafter. > > Individual ports can also declare that certain variants should be on by > default. For example wireshark turns most of its variants on by default, > including the lua variant. You can see this by running "port variants > wireshark" or "port info wireshark"; the variant names that are preceded by > "[+]" are on by default. If you don't want some of those variants, explicitly > disable them when installing (and your choice will be remembered when > upgrading). > smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Quick question: how to "clear" earlier variants list?
On Sep 17, 2015, at 11:40 AM, Kennedy, Smith wrote: > I've been struggling with getting Wireshark 1.12.7 to build lately - there > seems to be some issue with the Lua bindings. I tried to disable the Lua > bindings in the build, but the set of variants I had previously set seem to > be "sticky", even after I do a "sudo port clean --all wireshark". What else > do I need to do to clear out the previously set of variants? Variants are intended to be sticky to the extent that if you install a port with a particular set of variants, that set of variants will be preserved when you later upgrade the port. If you don't want that, install (not upgrade) the port, with the set of variants you want. Variants are also intended to be sticky to the extent that if you list some variants in the variants.conf file, that list of variants will be used for any port you install thereafter. Individual ports can also declare that certain variants should be on by default. For example wireshark turns most of its variants on by default, including the lua variant. You can see this by running "port variants wireshark" or "port info wireshark"; the variant names that are preceded by "[+]" are on by default. If you don't want some of those variants, explicitly disable them when installing (and your choice will be remembered when upgrading). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Standalone tickets for qt4-mac variants and patches
FYI, I just submitted standalone tickets for variants and patches included in my qt4-mac concurrent ticket but not related to making Qt4 co-installable : #46606: qt4-mac noexceptions variant Ticket URL: https://trac.macports.org/ticket/46606 #46607: qt4-mac +KDE variant. Ticket URL: https://trac.macports.org/ticket/46607 #46608: qt4-mac: avoid zombie processes Ticket URL: https://trac.macports.org/ticket/46608 BR, R.B. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
non-existent variants
Hello, I just discovered that installing a port with a +unexisting variant goes through without as much as a warning. A bit annoying if the install involves a lengthy build process and you don't notice that typo until some expected functionality proves to be absent ... Is there a reason for this omission? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: non-existent variants
Hi, - On 10 Oct, 2014, at 23:01, René J.V. Bertin rjvber...@gmail.com wrote: Is there a reason for this omission? Yes: Consider ports A - B - C - D, where - is depends on. A has no variants, B has +foo, C has +bar and D has +baz sudo port install A +foo +bar +baz will install A B +foo C +bar D +baz, but we actually don't know which variants exist in a Portfile until we've run it. To avoid running a Portfile twice, MacPorts doesn't check whether you actually specified a variant that exists. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: non-existent variants
On Saturday October 11 2014 00:43:19 Clemens Lang wrote: Is there a reason for this omission? Yes: Consider ports A - B - C - D, where - is depends on. A has no variants, B has +foo, C has +bar and D has +baz Yes, I see. But that situation could also have been addressed by disabling the check through an additional option or env.variable, no? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: non-existent variants
On Oct 10, 2014, at 6:06 PM, René J.V. Bertin wrote: On Saturday October 11 2014 00:43:19 Clemens Lang wrote: Is there a reason for this omission? Yes: Consider ports A - B - C - D, where - is depends on. A has no variants, B has +foo, C has +bar and D has +baz Yes, I see. But that situation could also have been addressed by disabling the check through an additional option or env.variable, no? What do you mean? Disabling what check? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
How to find default variants
Before installing a port, how does one discover the default variants for that port? I gather that one could search the port text file for default_variants but it seems like there should be a command for this, perhaps port default_variants foo. Jerry ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: How to find default variants
Port variants. It indicates which variants are on based on your variants.conf On July 5, 2014 8:52:08 PM EDT, Jerry lancebo...@qwest.net wrote: Before installing a port, how does one discover the default variants for that port? I gather that one could search the port text file for default_variants but it seems like there should be a command for this, perhaps port default_variants foo. Jerry ___ 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: How to find default variants
On Jul 5, 2014, at 7:54 PM, Jeremy Lavergne wrote: Port variants. It indicates which variants are on based on your variants.conf ...and based on the port's defaults. For example: $ port variants xorg-libxcb xorg-libxcb has the variants: docs: Install extra documentation python25: Use python 2.5 * conflicts with python26 python27 python31 python32 python33 python26: Use python 2.6 * conflicts with python25 python27 python31 python32 python33 [+]python27: Use python 2.7 * conflicts with python25 python26 python31 python32 python33 python31: Use python 3.1 * conflicts with python25 python26 python27 python32 python33 python32: Use python 3.2 * conflicts with python25 python26 python27 python31 python33 python33: Use python 3.3 * conflicts with python25 python26 python27 python31 python32 (+)universal: Build for multiple architectures This shows the variants that are available in the xorg-libxcb port. Also, the [+] indicator next to the python27 variant means that the portfile turns that variant on by default, while the (+) indicator means I've requested that variant in my variants.conf file. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Portfile variants vs. subports recommendation
On Jun 12, 2014, at 8:13 PM, Jason Mitchell jason-macpo...@maiar.org wrote:
Hello,
For projects with several forks, i.e. more than stable and devel, what
is the preferred Portfile treatment? Consider git-flow, which uses the
canonical nvie GitHub (GH) repository that is inactive. Of nvie's ~1000
forks, at least 2 are useful:
- petervanderdoes/gitflow: AVH Edition
- datasift/gitflow: HubFlow (GH tweaked, different git trigger)
Options considered:
1. git-flow Portfile w/ nvie as default (variant), w/ +avh +hubflow;
each variant conflicts with others
2. git-flow Portfile w/ separate named subports, e.g.
git-flow-{nvie,avh,hubflow}; nvie and avh conflict
3. combination of #1 #2, w/ variants on default port set depends
Based on gnuradio, it seems #2 is preferred, then let the end-user
decide. #2 also seems easier to make gitflow variants directly on git.
Option 2 is definitely preferred. The problem with variants is that other ports
cannot depend on them. At best a Portfile can use the active_variants portgroup
to require a port with a non-default variant. But these will never get built on
the buildbot since it only builds a port with the default variants.
Cheers!
Frank
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Portfile variants vs. subports recommendation
On Jun 13, 2014, at 3:23 AM, René J.V. Bertin rjvber...@gmail.com wrote: On Thursday June 12 2014 22:13:34 Jason Mitchell wrote: Hello, For projects with several forks, i.e. more than stable and devel, what is the preferred Portfile treatment? Consider git-flow, which uses the canonical nvie GitHub (GH) repository that is inactive. Of nvie's ~1000 forks, at least 2 are useful: I'd have a similar question for the oxygen-gtk port I've proposed. It exists for GTk2 and GTk3, and while they have their own versioning scheme/schedule it could make sense to treat them as subports ... if of course that allows to install both at the same time. Yes, subports would be the way to go, have oxygen-gtk2 and oxygen-gtk3 ports. Cheers! Frank ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Portfile variants vs. subports recommendation
Hello,
For projects with several forks, i.e. more than stable and devel, what
is the preferred Portfile treatment? Consider git-flow, which uses the
canonical nvie GitHub (GH) repository that is inactive. Of nvie's ~1000
forks, at least 2 are useful:
- petervanderdoes/gitflow: AVH Edition
- datasift/gitflow: HubFlow (GH tweaked, different git trigger)
Options considered:
1. git-flow Portfile w/ nvie as default (variant), w/ +avh +hubflow;
each variant conflicts with others
2. git-flow Portfile w/ separate named subports, e.g.
git-flow-{nvie,avh,hubflow}; nvie and avh conflict
3. combination of #1 #2, w/ variants on default port set depends
Based on gnuradio, it seems #2 is preferred, then let the end-user
decide. #2 also seems easier to make gitflow variants directly on git.
Thanks,
-jason
Disclosure: I submitted the initial git-flow Portfile.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Problem reinstalling packages after Mavericks upgrade - variants conflict
Hi, I’ve ran into a problem when reinstalling my macports packages after the upgrade to Mavericks (as suggested in the Migration guide). I’m only installing the packages I actually requested, but now I’ve hit a behaviour which may be a bug. What I did was the following: Compile a list of of packages and variants that I actually wanted on the new machine. This list contained, among others, octave +atlas+gcc48” and “inkscape +python27+quartz”. Issued a single port install command containing this list of packages and variants. Port install then proceeded to install first octave and, among its dependents, cairo @1.12.16_2+x11. It then failed when installing inkscape, as the requested cairomm +quartz requires cairo +quartz. This problem was not flagged when running a dry-run install. Now the questions: Is there any way to find out beforehand that the combination of variants I requested are incompatible? Backtracking the whole install is a pain (and a time-consuming process as well). Does port install treat multiple requested ports as single transactions? Is this intentional or a bug? Should I put in a bug report? Is there any chance to get a behaviour akin to Fedora’s yum, where all requested ports are installed in a single transaction, i.e. the dependencies of all requested ports are resolved before a single port is installed. This feature would make bulk installs *much* smoother. Thank you, Peter ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: dbus obsolete variants?
On Thursday April 10 2014 20:52:14 Dominik Reichardt wrote: (it then eplaced dbus @1.6.12_0+startupitem+universal with dbus @1.8.0_0+universal) Can anyone explain this or tell me whether there needs to be done anything? If port installed dbus tells you you have the +universal version, you should be good. You could read through macports.conf to check if you like the default, but there's little chance you'll want to change them, given how you got dbus in the first place. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
dbus obsolete variants?
Hi all, today on selfupdate and upgrade, I got the following warning on upgrading dbus: Warning: You have requested an obsolete variant Warning: Installation of startup items are now determined by /opt/local/etc/macports/macports.conf Warning: See https://guide.macports.org/#reference.startupitems (it then eplaced dbus @1.6.12_0+startupitem+universal with dbus @1.8.0_0+universal) Can anyone explain this or tell me whether there needs to be done anything? dbus is not something I set out to install directly, but got installed through gimp, so I have no idea about startupitems and what changed or needs to be changed. https://guide.macports.org/#reference.startupitems doesn’t shed any light on this warning AFAICT. Thanks and take care Dominik___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: list active ports with non-default variants
On Thu, Mar 6, 2014 at 12:48 PM, Bradley Giesbrecht pixi...@macports.org wrote: Does anyone have a command for listing active ports with non-default variants? I'm not aware of any, but I'd love to find there is one. I usually end up dumping a list of installed ports to a file and then removing variants that I know are in my default configuration. Then I go port by port, comparing what's left. I'd love a command like port installed --without-default-variants that would omit variants that are enabled by befault by the port or user configuration. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: list active ports with non-default variants
Don’t forget have that third state: set as default in the variants.conf file but not really a default. How should that be represented here? On Mar 6, 2014, at 13:51, Arno Hautala a...@alum.wpi.edu wrote: I'm not aware of any, but I'd love to find there is one. I usually end up dumping a list of installed ports to a file and then removing variants that I know are in my default configuration. Then I go port by port, comparing what's left. I'd love a command like port installed --without-default-variants that would omit variants that are enabled by befault by the port or user configuration. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: list active ports with non-default variants
Hi, Does anyone have a command for listing active ports with non-default variants? I'm not aware of any, but I'd love to find there is one. I usually end up dumping a list of installed ports to a file and then removing variants that I know are in my default configuration. Then I go port by port, comparing what's left. I'd love a command like port installed --without-default-variants that would omit variants that are enabled by befault by the port or user configuration. We should really extend the requested mechanism to track user-requested variants. That would also give us a clean upgrade path when changing default variants. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
all variants which use x11?
How do I find the list of currently installed ports which use x11 rather than quartz? I have a bunch of ports which still specify +x11 and I want to remove them, reinstall with +quartz as a uniform option. Thanks. Comer *Comer Duncan* *, Bowling Green State University 1970-2005* ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: all variants which use x11?
`port -v installed` will show the variant selection for installed ports. You’ll probably want to use `port upgrade —enforce-variants …` to switch ports the variants you want. On Oct 28, 2013, at 16:18, Comer Duncan comer.dun...@gmail.com wrote: How do I find the list of currently installed ports which use x11 rather than quartz? I have a bunch of ports which still specify +x11 and I want to remove them, reinstall with +quartz as a uniform option. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Multiple Variants
On Tue, Oct 22, 2013 at 8:09 AM, Derek Ng acecali...@gmail.com wrote: Can you install and have multiple variants active at the same time? Or are you limited to only one active variant, and then you have to switch between them? You have to switch between them; since the only thing that changes is build options, they want to live in the same paths. -- 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: Multiple Variants
On Tue, Oct 22, 2013 at 08:09:20AM -0400, Derek Ng wrote: Can you install and have multiple variants active at the same time? Or are you limited to only one active variant, and then you have to switch between them? If you're talking about something like cairo +quartz+x11, or vim +huge+python27 that's certainly possible. If you're talking about having a copy of cairo +x11, and cario +quartz and those active at the same time, that's not possible, which is what Brandon is referring to. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
RE: Multiple Variants
Thanks! I was referring to the first option. So I guess to install vim with both huge and python27 functionality, I would use this install command? port install vim +huge +python27 i.e., vim will have both functionalities without having to switch from one to the other? -Original Message- From: Clemens Lang [mailto:neverpa...@gmail.com] On Behalf Of Clemens Lang Sent: October-22-13 9:09 AM To: Derek Ng Cc: macports-users@lists.macosforge.org Subject: Re: Multiple Variants On Tue, Oct 22, 2013 at 08:09:20AM -0400, Derek Ng wrote: Can you install and have multiple variants active at the same time? Or are you limited to only one active variant, and then you have to switch between them? If you're talking about something like cairo +quartz+x11, or vim +huge+python27 that's certainly possible. If you're talking about having a copy of cairo +x11, and cario +quartz and those active at the same time, that's not possible, which is what Brandon is referring to. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Multiple Variants
On 22/10/13 14:31, Derek Ng wrote: Thanks! I was referring to the first option. So I guess to install vim with both huge and python27 functionality, I would use this install command? port install vim +huge +python27 i.e., vim will have both functionalities without having to switch from one to the other? correct. You can enable as many variants as you like, as long as they don't conflict with each other (which if the Portfile is properly set up will not be allowed). -Original Message- From: Clemens Lang [mailto:neverpa...@gmail.com] On Behalf Of Clemens Lang Sent: October-22-13 9:09 AM To: Derek Ng Cc: macports-users@lists.macosforge.org Subject: Re: Multiple Variants On Tue, Oct 22, 2013 at 08:09:20AM -0400, Derek Ng wrote: Can you install and have multiple variants active at the same time? Or are you limited to only one active variant, and then you have to switch between them? If you're talking about something like cairo +quartz+x11, or vim +huge+python27 that's certainly possible. If you're talking about having a copy of cairo +x11, and cario +quartz and those active at the same time, that's not possible, which is what Brandon is referring to. -- Clemens Lang ___ 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: Multiple Variants
On Oct 22, 2013, at 08:31, Derek Ng wrote: Thanks! I was referring to the first option. So I guess to install vim with both huge and python27 functionality, I would use this install command? port install vim +huge +python27 i.e., vim will have both functionalities without having to switch from one to the other? Exactly. You can use port variants vim to see what variants are available and what variants they conflict with, or you can just try the install and if the variants you've asked for conflict, MacPorts will tell you. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Question about +quartz vs. +x11 variants
On Thu, Jun 20, 2013 at 1:13 PM, David Favor da...@davidfavor.com wrote: As these are mutually exclusive someone clarify the differences. 1) It appears specifying a +quartz variant uses http://xquartz.macosforge.org/ code installed on a machine. Yes/No? No. +quartz means use native Mac OS X graphics, not any X11 implementation. 2) How does http://xquartz.macosforge.org/ relate to the quartz-wm port? Specifically, port install quartz-wm + quartz-wm --version produces version 1.3.1 while the XQuartz site shows version 2.7.4 + the XQuartz site implies quartz-wm is part of it's code (The quartz-wm window manager included with the XQuartz distribution...) The individual ports comprising X11 in MacPorts are the same as the distribution at http://xquartz.macosforge.org, aside from differing paths. They also have the same maintainer. But individual components (xorg-server, quartz-wm, xterm, etc.) have their own version numbers, which are reflected in the port versions; you would have to read the release notes in the XQuartz distribution to see these for the dmg distribution. 3) Last. Seems like XQuartz is more up to date code than X11. Is there any situation where +x11 variant is preferred over +quartz? This question is somewhat incorrect given that +quartz does not refer to an X11 distribution at all. But there are a number of Gtk+-based programs which, while they can build using the native or X11 versions of the toolkit, don't behave correctly with native graphics. (One example is that xchat using the native toolkit doesn't scroll chat windows properly.) -- 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: Question about +quartz vs. +x11 variants
On Jun 20, 2013, at 12:13, David Favor wrote: As these are mutually exclusive Not in all ports. Some ports, libraries in particular, can often be installed with support for both X11 and Quartz graphics. someone clarify the differences. 1) It appears specifying a +quartz variant uses http://xquartz.macosforge.org/ code installed on a machine. Yes/No? No, +quartz uses OS X's native Quartz graphics: http://en.wikipedia.org/wiki/Quartz_(graphics_layer) +x11 uses X11 graphics: http://en.wikipedia.org/wiki/X11 The XQuartz project is an unfortunately-named package. It is a collection of X11 software built for OS X. It provides an X11 interface for OS X. Programs communicate with XQuartz using the X11 interface, not the Quartz interface. (The Quartz interface is built into OS X and no other libraries are required to use it beyond those that come with OS X.) 2) How does http://xquartz.macosforge.org/ relate to the quartz-wm port? Specifically, port install quartz-wm + quartz-wm --version produces version 1.3.1 while the XQuartz site shows version 2.7.4 + the XQuartz site implies quartz-wm is part of it's code (The quartz-wm window manager included with the XQuartz distribution...) So to use latest version of XQuartz, does this require installing the .dmg file from the XQuartz site? XQuartz has its own versioning scheme. 2.7.4 only tells you the version number of that particular XQuartz collection. It does not tell you the version number of quartz-wm or any of the hundreds of other parts of the X11 system contained within XQuartz. Apple used to include X11 in OS X. The way they did so was to include the then-current version of XQuartz in OS X. But Apple seldom updated this throughout the life of a version of OS X so it became out of date. Users could elect to update their X11 manually by installing a newer version of XQuartz. Now, Apple has removed X11 from OS X, so if you want X11 at all, and are not using MacPorts, you must install XQuartz. This ensures you'll get a current version and not an old one. If you are using MacPorts, then installing the xorg ports is probably better, since it keeps more of your software in the MacPorts system (one place to update all your software), and it's probably more up to date than XQuartz, since each component is updated in MacPorts when it's ready, instead of having to bundle them all into a single distribution. The XQuartz package and the xorg ports in MacPorts are maintained by the same person at Apple so they are the same software. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Mar 24, 2013, at 18:35, Lawrence Velázquez wrote: Would it indeed be wise to install clang 3.2 or 3.3 You can certainly install any compiler port and use it to build individual ports. You can do this by setting configure.compiler on the command line. sudo port install foo configure.compiler=macports-clang-3.2 The valid values for configure.compiler are listed in UsingTheRightCompiler. Setting configure.compiler on the command line is intended for testing purposes, as a means for discovering what happens with different compilers, with the ultimate goal of updating the portfile's compiler selection. It's not intended for regular use during the normal course of installing ports. Probably the vast majority of ports are not tested with non-default compilers, so you may run into additional problems that nobody has seen before. And setting configure.compiler on the command line completely overrides the portfile's compiler choice, *including* compiler.blacklist. So even if a portfile author has already indicated that a port will not work with that compiler, by setting it on the command line, you'll be trying to use it anyway. Best case, the port will fail to build; worst case, the build might succeed but have runtime errors. I would like for MacPorts base to at least print a warning when you ask for a compiler that a port has already blacklisted, but it does not currently do this. If so, how does one set the default compiler in MacPorts? MacPorts will read default_compiler from macports.conf, but this is unsupported, and I really do not recommend using this. It should not be necessary and would be suboptimal for us because it would mask build issues with Xcode's compilers. We'd prefer to fix ports so that they build correctly on as many OS X versions as possible, without any manual compiler selection; if you encounter problems using a particular compiler to build a particular port, please file a ticket. *If* you want to override the default compiler always, then setting default_compiler in macports.conf is best, since it will respect any blacklists or whitelists specified in ports. However, again, because most users and developers don't test with non-default compilers, it's possible that you'll encounter errors we haven't seen before. For example, portfile authors might have discovered that a port does not build with clang, and so they might blacklist clang, but that would only cover the clang that comes with Xcode, and MacPorts clang compilers, though they would also not work for this hypothetical port, would still be allowed, and would then fail. Yes we should be fixing these problems in the ports (ideally by fixing the build with clang, or at least by properly blacklisting all the clang versions that won't work) but by changing your default compiler you may be signing yourself up for a disproportionate amount of work in reporting these problems to us. MacPorts 2.2 will make it easier for portfile authors to blacklist all versions of a compiler. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Sun, Mar 24, 2013 at 7:45 PM, Lawrence Velázquez lar...@macports.org wrote: Not only would it waste space, it would prevent you from using our pre-built binaries for nearly all ports. We only build +universal packages for dependencies of i386-only ports. How does one access these binaries? I'd *much* prefer to obtain binaries than compile from source on my archaic machine. -p. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Mar 25, 2013, at 6:15 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
How does one access these binaries? I'd *much* prefer to obtain
binaries than compile from source on my archaic machine.
By default they get used. They're referred to as archives in the internals
(e.g. port {archive,archivefetch,unarchive} zlib)
You can require their use with the -b flag (binary), or exclude them with -s
(source):
sudo port -b install zlib
sudo port -s install zlib
Also, they're only available for 64-bit OS X 10.6, 10.7, and 10.8. We have
archives for the default variants of those ports that can be distributed in
binary form according to their licenses. We also have archives for the
+universal variants of the dependencies of i386-only ports.
When installing a port, you can tell whether a binary was used if the output
shows port(1) fetching a tarball and an rmd160 signature and then jumping
straight to the install phase.
vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Mar 25, 2013, at 12:55, Peter Johansson wrote: On Sun, Mar 24, 2013 at 7:45 PM, Lawrence Velázquez wrote: Not only would it waste space, it would prevent you from using our pre-built binaries for nearly all ports. We only build +universal packages for dependencies of i386-only ports. How does one access these binaries? I'd *much* prefer to obtain binaries than compile from source on my archaic machine. MacPorts will automatically fetch and use these binaries if they're available, assuming you have not set buildfromsource always in macports.conf. You must use the default MacPorts prefix /opt/local, default applications_dir /Applications/MacPorts, default frameworks_dir /opt/local/Library/Frameworks, default build_arch x86_64, and default variants. Also as Larry said binaries are only available for Snow Leopard, Lion and Mountain Lion at this time. Also binaries are not available for all ports, often due to license restrictions. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Mar 24, 2013, at 12:53, Peter Johansson wrote: Greetings all! I am new to this mailing list but not MacPorts. I have been using it for about six years now, mostly for small command line apps - wget, sox, things of that nature. Somewhat recently I started using it for larger tools like Wine and gerbv. While I had some minor problems, I was able to build what I needed without much difficulty. Welcome to the list! I recently upgraded my machine (yes, the same one I bought six+ years ago) with a SSD, and took the opportunity for a completely fresh re-install. I am still running Snow Leopard but I upgraded to the latest XCode for SL, XCode 4.2. This caused a bunch of problems which I eventually tracked down to a problem with the clang compiler shipped with XCode 4.2 -- it does not properly respect CPATH causing a whole bunch of things to fail. In the process of building a working system, I got sucked into a little more of the nitty gritty than I had hoped. Yes, that's correct, old versions of clang (those in Xcode 4.3.x and earlier, as I recall) do not honor CPATH, and this is often a problem. Although I have read the page Using the Right Compiler this page does not actually provide any insight as to which compiler should be used to build the MacPorts tree, particularly on older systems with rather outdated system compilers. It seems as if MacPorts prefers clang, but by default it uses your system's default clang. While this is probably best if you are running the latest XCode, this is clearly not optimal if you are limited to an older version of XCode. MacPorts chooses the default compiler based on the Xcode version: For Xcode 2.x (Tiger) and Xcode 3.0.x and 3.1.x (Leopard) the default is gcc-4.0. For Xcode 3.2.x (Snow Leopard) the default is gcc-4.2. For Xcode 4.0.x (Snow Leopard) and 4.1.x (Snow Leopard and Lion) the default is llvm-gcc-4.2. For Xcode 4.2.x and above (Snow Leopard and later) the default is clang. Xcode 4.2.x and above no longer include any version of gcc. And it has been announced in the Xcode 4.6 release notes that it is the last version that will include llvm-gcc, leaving only clang going forward. We know that Apple believes llvm and clang are the future of compiling on OS X, which is why we began pushing toward this in the default compiler selection. However, as you discovered, the by now quite old versions of clang in Xcode 4.2.x and earlier have some deficiencies compared with current versions. The problem is worsened by the fact that Xcode 4.2.x is not in very common use. Xcode 4 for Snow Leopard is not available for free; you can only get it if you have a paid Apple Developer account. And on Lion, users are upgrading to the latest version, 4.6.1. So by using Xcode 4.2 you're likely to encounter problems others haven't encountered and will have difficulty reproducing and fixing. Additional problems can occur for Xcode 4.2 users on Snow Leopard who already built some ports while using Xcode 3.2.x, or who get binaries from our build server, which uses Xcode 3.2.6. A few ports keep track of what compiler was used to compile them, and try to enforce the use of that compiler for related ports. This can be a problem if, for example, you install a port X with Xcode 3.2.6 which will therefore use gcc-4.2, and you then try to install a port Y (which depends on port X) with Xcode 4.2 which does not have gcc-4.2. You can avoid these problems by disabling the use of our pre-built binaries (set buildfromsource always in macports.conf) and uninstalling and reinstalling all ports after upgrading to Xcode 4.2. Unless you have a specific need for Xcode 4.2, on Snow Leopard you may be better off using Xcode 3.2.6. Now onto Variants... When I built Wine on my previous system, it seems as if every package used by Wine got recompiled as a +universal variant. I assume this is because Wine only runs under i386 arch. Yes, that is correct. I noticed in several places it was suggested to make +universal the default variant on systems running 64-bit kernels, even aside from Wine. Is this actually a good procedure? I do this on my system, but only because I want as many of our ports to build universal as possible, so I want to know about problems right away so that I can fix or report them. If you don't enjoy encountering and reporting problems, and would rather that things just work more of the time, and if you don't usually require 32-bit versions of your software in addition to the normal 64-bit versions, then don't put +universal into variants.conf. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Compilers and Variants and Architectures Oh My!
Greetings all! I am new to this mailing list but not MacPorts. I have been using it for about six years now, mostly for small command line apps - wget, sox, things of that nature. Somewhat recently I started using it for larger tools like Wine and gerbv. While I had some minor problems, I was able to build what I needed without much difficulty. I recently upgraded my machine (yes, the same one I bought six+ years ago) with a SSD, and took the opportunity for a completely fresh re-install. I am still running Snow Leopard but I upgraded to the latest XCode for SL, XCode 4.2. This caused a bunch of problems which I eventually tracked down to a problem with the clang compiler shipped with XCode 4.2 -- it does not properly respect CPATH causing a whole bunch of things to fail. In the process of building a working system, I got sucked into a little more of the nitty gritty than I had hoped. Although I have read the page Using the Right Compiler this page does not actually provide any insight as to which compiler should be used to build the MacPorts tree, particularly on older systems with rather outdated system compilers. It seems as if MacPorts prefers clang, but by default it uses your system's default clang. While this is probably best if you are running the latest XCode, this is clearly not optimal if you are limited to an older version of XCode. Would it indeed be wise to install clang 3.2 or 3.3 and then set this to the default compiler for MacPorts? If so, how does one set the default compiler in MacPorts? Furthermore, would it be wise to build a bootstrap install of MacPorts to obtain the desired compiler, and then use this to build the primary MacPorts install? Now onto Variants... When I built Wine on my previous system, it seems as if every package used by Wine got recompiled as a +universal variant. I assume this is because Wine only runs under i386 arch. I noticed in several places it was suggested to make +universal the default variant on systems running 64-bit kernels, even aside from Wine. Is this actually a good procedure? It does seem to break some software, most notably msp430-gcc built outside of MacPorts, and the AVR tools within MacPorts. Can someone explain how libraries are managed when compiled with +universal? Does this build both architectures into a single library, or are multiple libraries created for each architecture? What is the proper way to install packages like avr-binutils that do not have a +universal variant, when +universal is selected as a system default? I realize there are a lot of questions here, and I am probably not asking some of them properly, but any assistance that can be provided here would be most appreciated. -p. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
Although I have read the page Using the Right Compiler this page does not actually provide any insight as to which compiler should be used to build the MacPorts tree, particularly on older systems with rather outdated system compilers. It seems as if MacPorts prefers clang, but by default it uses your system's default clang. While this is probably best if you are running the latest XCode, this is clearly not optimal if you are limited to an older version of XCode. Would it indeed be wise to install clang 3.2 or 3.3 and then set this to the default compiler for MacPorts? If so, how does one set the default compiler in MacPorts? Furthermore, would it be wise to build a bootstrap install of MacPorts to obtain the desired compiler, and then use this to build the primary MacPorts install? The default compilers are listed here: https://trac.macports.org/browser/trunk/base/src/port1.0/portconfigure.tcl#L443 Only 10.4 has an OS-specific check due to the differently-named SDK from Apple; everything else operates based on Xcode version. You can override the defaults in a Portfile using whitelists and blacklists or you can edit the MacPorts source and build/install it. Just be mindful that running selfupdate may eventually replace what you've installed. Now onto Variants... When I built Wine on my previous system, it seems as if every package used by Wine got recompiled as a +universal variant. I assume this is because Wine only runs under i386 arch. I noticed in several places it was suggested to make +universal the default variant on systems running 64-bit kernels, even aside from Wine. Is this actually a good procedure? It does seem to break some software, most notably msp430-gcc built outside of MacPorts, and the AVR tools within MacPorts. You're right that +universal was triggered due to wine. In this case it is needed to provide the default native architecture (x86_64) where available while providing a stack for the other architecture that wine needs (i386). You certainly can always build +universal anyways, but it tends to be a waste of space unless you know you'll need it. Another option is changing the default architecture (build_arch in macports.conf) to i386. On Mac OS X 10.6 the default is x86_64 if the CPU supports it, i386 otherwise. Can someone explain how libraries are managed when compiled with +universal? Does this build both architectures into a single library, or are multiple libraries created for each architecture? What is the proper way to install packages like avr-binutils that do not have a +universal variant, when +universal is selected as a system default? Yes, both architectures go into a single library. If a package has its universal variant disabled there is likely some actual issue. All crossbinutils (e.g. avr-binutils) have their universal variants diabled. Here's an example +universal library. $ file libatk-1.0.0.dylib libatk-1.0.0.dylib: Mach-O fat file with 2 architectures: [ X86_64: Mach-O 64-bit x86_64 dynamically linked shared library ] [ I386: Mach-O i386 dynamically linked shared library ] After installation, you can see what files were installed by a given port via `port contents PORTNAME`. Similarly, MacPorts can tell you what architectures were asked for during installation via `port -v installed [PORTNAME]`. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Mar 24, 2013, at 1:53 PM, Peter Johansson rockets4k...@gmail.com wrote: I am still running Snow Leopard but I upgraded to the latest XCode for SL, XCode 4.2. This caused a bunch of problems which I eventually tracked down to a problem with the clang compiler shipped with XCode 4.2 -- it does not properly respect CPATH causing a whole bunch of things to fail. If these were problems with MacPorts or ports, please submit bug reports so we can try fixing them. http://guide.macports.org/chunked/project.html#project.tickets Although I have read the page Using the Right Compiler this page does not actually provide any insight as to which compiler should be used to build the MacPorts tree, particularly on older systems with rather outdated system compilers. Using the Right Compiler is really a guide for portfile authors. Build systems often try to choose compilers on their own, but we want to ensure that MacPorts' chosen compiler is used instead. It seems as if MacPorts prefers clang, but by default it uses your system's default clang. While this is probably best if you are running the latest XCode, this is clearly not optimal if you are limited to an older version of XCode. I assume you're talking about the compiler chosen to build ports. MacPorts picks a compiler from a fallback list of compilers, chosen based on Xcode version. Individual ports may specify a blacklist of incompatible compilers that should *not* be used. They may also specify a whitelist of compilers that *can* be used; this would override MacPorts' fallback list entirely. For instance, in the current release, the fallback list for Xcode 4.2 contains, in this order: - Clang from Xcode, - LLVM-GCC 4.2 from Xcode, and - Apple's custom GCC 4.2 from MacPorts' apple-gcc42 port. If a port does not compile correctly with Xcode's Clang, it can blacklist it; then LLVM-GCC would be used instead. (Ideally this would be fixed upstream at some point.) Would it indeed be wise to install clang 3.2 or 3.3 You can certainly install any compiler port and use it to build individual ports. You can do this by setting configure.compiler on the command line. sudo port install foo configure.compiler=macports-clang-3.2 The valid values for configure.compiler are listed in UsingTheRightCompiler. If so, how does one set the default compiler in MacPorts? MacPorts will read default_compiler from macports.conf, but this is unsupported, and I really do not recommend using this. It should not be necessary and would be suboptimal for us because it would mask build issues with Xcode's compilers. We'd prefer to fix ports so that they build correctly on as many OS X versions as possible, without any manual compiler selection; if you encounter problems using a particular compiler to build a particular port, please file a ticket. Furthermore, would it be wise to build a bootstrap install of MacPorts to obtain the desired compiler, and then use this to build the primary MacPorts install? Are you talking about installing ports, or building MacPorts base? Bootstrapping should not be necessary in either case. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Compilers and Variants and Architectures Oh My!
On Mar 24, 2013, at 2:53 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: I noticed in several places it was suggested to make +universal the default variant on systems running 64-bit kernels, even aside from Wine. Is this actually a good procedure? You certainly can always build +universal anyways, but it tends to be a waste of space unless you know you'll need it. Not only would it waste space, it would prevent you from using our pre-built binaries for nearly all ports. We only build +universal packages for dependencies of i386-only ports. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
OpenCV port variants
Hello, MacPorts n00b here. I'm learning OpenCV and have used MacPorts for the install using the default install: sudo port install opencv I'm not sure if it was installed with Qt4 support or Python support though. I've also installed Pallet and noticed variants such as qt4 and python26. Is it possible to 'update'/change the port install to also include qt4 and python26 ? If so, what commands do I run ? Otherwise, what are my alternatives ? Thank you for your time, George ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenCV port variants
On Wed, Aug 01, 2012 at 10:02:02AM +0100, George Profenza wrote: I'm not sure if it was installed with Qt4 support or Python support though. In that case it probably didn't add python or qt4 support, because opencv has variants to provide this support; see: `port variants opencv` Is it possible to 'update'/change the port install to also include qt4 and python26 ? If so, what commands do I run ? Otherwise, what are my alternatives ? If you want qt4 and python26 you could run `sudo port upgrade --enforce-variants opencv +qt4 +python26` or for python27 `sudo port upgrade --enforce-variants opencv +qt4 +python27` -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenCV port variants
Woo hoo! clean and upgrade worked fine ! Thanks again! On Wed, Aug 1, 2012 at 12:46 PM, Clemens Lang c...@macports.org wrote: On Wed, Aug 01, 2012 at 12:40:30PM +0100, George Profenza wrote: Is there a way to enforce qt4 and python27 variants on the existing port 2.4.1 port ? MacPorts will always build whatever is the latest version in the ports tree. If you really need 2.4.1 for some obscure reason you can use http://trac.macports.org/wiki/howto/InstallingOlderPort. However, I'm not sure why this would fail with this error message. Can you clean opencv, re-try and attach the logfile or open a ticket and attach it there if it fails again? If you open a ticket, feel free to assign it to c...@macports.org. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenCV port variants
Sorry to bother again, Got another question related to the OpenCV port. Is there a way to find out if the OpenCV port is installed with OpenNI support ? If so, how ? If it's not built with OpenNI support, how can I tell MacPorts to rebuilt the library with OpenNI support ? Thank you, George On Wed, Aug 1, 2012 at 2:40 PM, George Profenza orgi...@gmail.com wrote: Woo hoo! clean and upgrade worked fine ! Thanks again! On Wed, Aug 1, 2012 at 12:46 PM, Clemens Lang c...@macports.org wrote: On Wed, Aug 01, 2012 at 12:40:30PM +0100, George Profenza wrote: Is there a way to enforce qt4 and python27 variants on the existing port 2.4.1 port ? MacPorts will always build whatever is the latest version in the ports tree. If you really need 2.4.1 for some obscure reason you can use http://trac.macports.org/wiki/howto/InstallingOlderPort. However, I'm not sure why this would fail with this error message. Can you clean opencv, re-try and attach the logfile or open a ticket and attach it there if it fails again? If you open a ticket, feel free to assign it to c...@macports.org. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenCV port variants
On Aug 1, 2012, at 04:02, George Profenza orgi...@gmail.com wrote: I'm learning OpenCV and have used MacPorts for the install using the default install: sudo port install opencv I'm not sure if it was installed with Qt4 support or Python support though. I've also installed Pallet and noticed variants such as qt4 and python26. You can see what variants a port was installed with by running e.g. port installed opencv On Aug 1, 2012, at 04:58, George Profenza orgi...@gmail.com wrote: On Aug 1, 2012, at 04:32, Clemens Lang c...@macports.org wrote: If you want qt4 and python26 you could run `sudo port upgrade --enforce-variants opencv +qt4 +python26` or for python27 `sudo port upgrade --enforce-variants opencv +qt4 +python27` I've got an error when trying to enforce the python26 variant: Error: xorg-libxcb: Variant python26 conflicts with python27 Error: Unable to open port: Error evaluating variants To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Yeah… the problem is xorg-libxcb has python variants too, and you happened to have it installed with the python27 variant already. Now when trying to upgrade, MacPorts is trying to *add* to the python26 variant to that, which is incompatible. To get this to work you would have to also specify that you *don't* want to use the python27 variant anymore, like this: sudo port upgrade --enforce-variants opencv +qt4 +python26 -python27 Or, better yet, do what you already did, and install with the python27 variant, since that's newer and better. On Aug 1, 2012, at 06:46, Clemens Lang c...@macports.org wrote: On Aug 1, 2012, at 06:40, George Profenza orgi...@gmail.com wrote: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_opencv/opencv/work/OpenCV-2.4.2: No such file or directory MacPorts will always build whatever is the latest version in the ports tree. If you really need 2.4.1 for some obscure reason you can use http://trac.macports.org/wiki/howto/InstallingOlderPort. However, I'm not sure why this would fail with this error message. Can you clean opencv, re-try and attach the logfile or open a ticket and attach it there if it fails again? It failed because of #29223. Cleaning and trying again was the correct solution and is the first thing you should try anytime any port fails to install. On Aug 1, 2012, at 10:11, George Profenza orgi...@gmail.com wrote: Got another question related to the OpenCV port. Is there a way to find out if the OpenCV port is installed with OpenNI support ? If so, how ? If it's not built with OpenNI support, how can I tell MacPorts to rebuilt the library with OpenNI support ? There are no occurrences of the string OpenNI in the OpenCV Portfile. If OpenCV builds with OpenNI support by default, then it is on. If not, then it is off andMacPorts does not offer a way to turn it on, in which case you could file a ticket in our issue tracker requesting this feature. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenCV port variants
Thanks Ryan, This is very well explained, thanks! I've built with python27 and after cleaning all went well. For now I've also built OpenCV from source on an external hard drive without installing and set the OpenNI CMake flag on (which is off by default - and it makes sense since probably the majority of OpenCV user might not use OpenNI). For my OpenCV/OpenNI project I've copied the .dylibs built with OpenNI support in the project folder. In the future it would be cool if there would be an openni variant I could install: `sudo port upgrade --enforce-variants opencv +qt4 +python27 +openni` and I imagine other developers will benefit from this, but I don't see this suitable as a default. Thanks again, I appreciate the time taken to explain ! On Wed, Aug 1, 2012 at 7:28 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Aug 1, 2012, at 04:02, George Profenza orgi...@gmail.com wrote: I'm learning OpenCV and have used MacPorts for the install using the default install: sudo port install opencv I'm not sure if it was installed with Qt4 support or Python support though. I've also installed Pallet and noticed variants such as qt4 and python26. You can see what variants a port was installed with by running e.g. port installed opencv On Aug 1, 2012, at 04:58, George Profenza orgi...@gmail.com wrote: On Aug 1, 2012, at 04:32, Clemens Lang c...@macports.org wrote: If you want qt4 and python26 you could run `sudo port upgrade --enforce-variants opencv +qt4 +python26` or for python27 `sudo port upgrade --enforce-variants opencv +qt4 +python27` I've got an error when trying to enforce the python26 variant: Error: xorg-libxcb: Variant python26 conflicts with python27 Error: Unable to open port: Error evaluating variants To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Yeah… the problem is xorg-libxcb has python variants too, and you happened to have it installed with the python27 variant already. Now when trying to upgrade, MacPorts is trying to *add* to the python26 variant to that, which is incompatible. To get this to work you would have to also specify that you *don't* want to use the python27 variant anymore, like this: sudo port upgrade --enforce-variants opencv +qt4 +python26 -python27 Or, better yet, do what you already did, and install with the python27 variant, since that's newer and better. On Aug 1, 2012, at 06:46, Clemens Lang c...@macports.org wrote: On Aug 1, 2012, at 06:40, George Profenza orgi...@gmail.com wrote: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_opencv/opencv/work/OpenCV-2.4.2: No such file or directory MacPorts will always build whatever is the latest version in the ports tree. If you really need 2.4.1 for some obscure reason you can use http://trac.macports.org/wiki/howto/InstallingOlderPort. However, I'm not sure why this would fail with this error message. Can you clean opencv, re-try and attach the logfile or open a ticket and attach it there if it fails again? It failed because of #29223. Cleaning and trying again was the correct solution and is the first thing you should try anytime any port fails to install. On Aug 1, 2012, at 10:11, George Profenza orgi...@gmail.com wrote: Got another question related to the OpenCV port. Is there a way to find out if the OpenCV port is installed with OpenNI support ? If so, how ? If it's not built with OpenNI support, how can I tell MacPorts to rebuilt the library with OpenNI support ? There are no occurrences of the string OpenNI in the OpenCV Portfile. If OpenCV builds with OpenNI support by default, then it is on. If not, then it is off andMacPorts does not offer a way to turn it on, in which case you could file a ticket in our issue tracker requesting this feature. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenCV port variants
On Aug 1, 2012, at 13:39, George Profenza orgi...@gmail.com wrote: In the future it would be cool if there would be an openni variant I could install: `sudo port upgrade --enforce-variants opencv +qt4 +python27 +openni` and I imagine other developers will benefit from this, but I don't see this suitable as a default. That sounds like a good idea. Could you please file an issue in our ticket tracker about this? Thanks. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Cleanup of compiler variants in py-numpy and py-scipy
On Mon, Jul 9, 2012 at 6:07 PM, Adam Mercer r...@macports.org wrote: Currently py-numpy and py-scipy have the following compiler variants: gcc43, gcc44, gcc45, gcc46, and gcc47. Whereas the atlas port only provides variants using gcc45, gcc46, and gcc47. Therefore I propose removing the gcc43, and gcc44 variants from py-numpy and py-scipy. Any objections? I'll take silence to mean no one has any objections, I'll remove the gcc43 and gcc44 variants over the weekend. Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Fail with 'sudo port upgrade --enforce-variants'
On Wed, Jun 20, 2012 at 1:33 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Error: Port cyrus-sasl2 is still broken after rebuiling it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Could you send us the output? port -d -y rev-upgrade https://trac.macports.org/ticket/35042 -- Robson Roberto Souza Peixoto Robinho Master in Computer Science, University of Campinas Linux Counter #395633 IRC: robsonpeixoto Twitter: http://twitter.com/rrspba github: https://github.com/robsonpeixoto ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Fail with 'sudo port upgrade --enforce-variants'
[robinho@robinho ~ ]$ sudo port upgrade --enforce-variants cyrus-sasl2 -kerberos +sql Password: --- Computing dependencies for cyrus-sasl2 --- Fetching archive for cyrus-sasl2 --- Attempting to fetch cyrus-sasl2-2.1.25_0+sql+universal.darwin_11.i386-x86_64.tbz2 from http://packages.macports.org/cyrus-sasl2 --- Fetching distfiles for cyrus-sasl2 --- Verifying checksum(s) for cyrus-sasl2 --- Extracting cyrus-sasl2 --- Applying patches to cyrus-sasl2 --- Configuring cyrus-sasl2 --- Building cyrus-sasl2 --- Staging cyrus-sasl2 into destroot --- Installing cyrus-sasl2 @2.1.25_0+sql+universal --- Cleaning cyrus-sasl2 --- Computing dependencies for cyrus-sasl2 --- Deactivating cyrus-sasl2 @2.1.25_0+kerberos+universal --- Cleaning cyrus-sasl2 --- Activating cyrus-sasl2 @2.1.25_0+sql+universal --- Cleaning cyrus-sasl2 --- Updating database of binaries: 100.0% --- Scanning binaries for linking errors: 100.0% --- Found 1 broken file(s), matching files to ports --- Found 1 broken port(s), determining rebuild order --- Rebuilding in order cyrus-sasl2 @2.1.25 +sql+universal-kerberos --- Computing dependencies for cyrus-sasl2 --- Cleaning cyrus-sasl2 --- Scanning binaries for linking errors: 100.0% --- Found 1 broken file(s), matching files to ports --- Found 1 broken port(s), determining rebuild order --- Rebuilding in order cyrus-sasl2 @2.1.25 +sql+universal-kerberos --- Computing dependencies for cyrus-sasl2 --- Cleaning cyrus-sasl2 --- Unable to uninstall cyrus-sasl2 @2.1.25_0+sql+universal, the following ports depend on it: ---subversion-javahlbindings @1.7.5_0+universal ---subversion @1.7.5_0+bash_completion+mod_dav_svn+tools+unicode_path+universal ---openldap @2.4.21_5+overlays+universal ---subversion-perlbindings @1.7.5_0 ---php53-ldap @5.3.14_0 ---php54-ldap @5.4.4_0 ---libmemcached @1.0.4_0 Warning: Uninstall forced. Proceeding despite dependencies. --- Deactivating cyrus-sasl2 @2.1.25_0+sql+universal --- Unable to deactivate cyrus-sasl2 @2.1.25_0+sql+universal, the following ports depend on it: ---subversion-javahlbindings @1.7.5_0+universal ---subversion @1.7.5_0+bash_completion+mod_dav_svn+tools+unicode_path+universal ---openldap @2.4.21_5+overlays+universal ---subversion-perlbindings @1.7.5_0 ---php53-ldap @5.3.14_0 ---php54-ldap @5.4.4_0 ---libmemcached @1.0.4_0 Warning: Deactivate forced. Proceeding despite dependencies. --- Cleaning cyrus-sasl2 --- Uninstalling cyrus-sasl2 @2.1.25_0+sql+universal --- Cleaning cyrus-sasl2 --- Computing dependencies for cyrus-sasl2 --- Fetching distfiles for cyrus-sasl2 --- Verifying checksum(s) for cyrus-sasl2 --- Extracting cyrus-sasl2 --- Applying patches to cyrus-sasl2 --- Configuring cyrus-sasl2 --- Building cyrus-sasl2 --- Staging cyrus-sasl2 into destroot --- Installing cyrus-sasl2 @2.1.25_0+sql+universal --- Activating cyrus-sasl2 @2.1.25_0+sql+universal --- Cleaning cyrus-sasl2 --- Updating database of binaries: 100.0% --- Scanning binaries for linking errors: 100.0% --- Found 1 broken file(s), matching files to ports --- Found 1 broken port(s), determining rebuild order --- Rebuilding in order cyrus-sasl2 @2.1.25 +sql+universal-kerberos --- Computing dependencies for cyrus-sasl2 --- Cleaning cyrus-sasl2 --- Unable to uninstall cyrus-sasl2 @2.1.25_0+sql+universal, the following ports depend on it: ---subversion-javahlbindings @1.7.5_0+universal ---subversion @1.7.5_0+bash_completion+mod_dav_svn+tools+unicode_path+universal ---openldap @2.4.21_5+overlays+universal ---subversion-perlbindings @1.7.5_0 ---php53-ldap @5.3.14_0 ---php54-ldap @5.4.4_0 ---libmemcached @1.0.4_0 Warning: Uninstall forced. Proceeding despite dependencies. --- Deactivating cyrus-sasl2 @2.1.25_0+sql+universal --- Unable to deactivate cyrus-sasl2 @2.1.25_0+sql+universal, the following ports depend on it: ---subversion-javahlbindings @1.7.5_0+universal ---subversion @1.7.5_0+bash_completion+mod_dav_svn+tools+unicode_path+universal ---openldap @2.4.21_5+overlays+universal ---subversion-perlbindings @1.7.5_0 ---php53-ldap @5.3.14_0 ---php54-ldap @5.4.4_0 ---libmemcached @1.0.4_0 Warning: Deactivate forced. Proceeding despite dependencies. --- Cleaning cyrus-sasl2 --- Uninstalling cyrus-sasl2 @2.1.25_0+sql+universal --- Cleaning cyrus-sasl2 --- Computing dependencies for cyrus-sasl2 --- Fetching distfiles for cyrus-sasl2 --- Verifying checksum(s) for cyrus-sasl2 --- Extracting cyrus-sasl2 --- Applying patches to cyrus-sasl2 --- Configuring cyrus-sasl2 --- Building cyrus-sasl2 --- Staging cyrus-sasl2 into destroot --- Installing cyrus-sasl2 @2.1.25_0+sql+universal --- Activating cyrus-sasl2 @2.1.25_0+sql+universal --- Cleaning cyrus-sasl2 --- Updating database of binaries: 100.0% --- Scanning binaries for linking errors: 100.0% --- Found 1 broken file(s), matching files to ports Error: Port cyrus
Re: Fail with 'sudo port upgrade --enforce-variants'
On Jun 19, 2012, at 19:33, Robson Roberto Souza Peixoto wrote: Error: Port cyrus-sasl2 is still broken after rebuiling it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Could you file a bug report please? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Fail with 'sudo port upgrade --enforce-variants'
Error: Port cyrus-sasl2 is still broken after rebuiling it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Could you send us the output? port -d -y rev-upgrade smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Exactly how do variants work?
On May 5, 2012, at 02:26, Bjarne D Mathiesen wrote: What port commands should I use to add a variant to an installed port? Do I need to uninstall and re-install the whole port? Yes, unfortunately that's how variants in MacPorts work. There's no distinction between variants that completely change how a port builds and those that just install extra files. How about subports ??? That might be a solution if it's really optional and really doesn't need a recompile of the primary port but 'just' installs some extra files. That's how eg mysql55 mysql55-server works Yes, now that we have subports, port maintainers should please break ports into subports where appropriate and feasible. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Exactly how do variants work?
My Macports installation has the following ports installed: qt4-mac @4.7.4_1+mysql+quartz kdegames4 @4.8.1_0 I would like to add variants +examples and +demos to qt4-mac and variant +docs to kdegames4. These variants do not require all of qt4-mac and kdegames4 to be downloaded, re-built and reinstalled. They are just extra files that can be separately installed and/or built. What port commands should I use to add a variant to an installed port? Do I need to uninstall and re-install the whole port? Also, to what extent are variant names local or global? I seem to remember that, when I added +mysql to qt4-mac, every other port in the tree that had a +mysql variant also got built. AFAIK +mysql for qt4-mac just adds some optional DB access classes to the library and builds a MySql driver for Qt to use. If variant names are indeed global, how would I avoid having every installed port that has variants +examples, +demos or +docs being re-installed? There are quite a few of them … Thanks, in advance. I have gone right through man port and the Macports Guide looking for answers to the above questions. Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Exactly how do variants work?
On May 4, 2012, at 20:45, Ian Wadham wrote: My Macports installation has the following ports installed: qt4-mac @4.7.4_1+mysql+quartz kdegames4 @4.8.1_0 I would like to add variants +examples and +demos to qt4-mac and variant +docs to kdegames4. These variants do not require all of qt4-mac and kdegames4 to be downloaded, re-built and reinstalled. They are just extra files that can be separately installed and/or built. What port commands should I use to add a variant to an installed port? Do I need to uninstall and re-install the whole port? Yes, unfortunately that's how variants in MacPorts work. There's no distinction between variants that completely change how a port builds and those that just install extra files. Also, to what extent are variant names local or global? I seem to remember that, when I added +mysql to qt4-mac, every other port in the tree that had a +mysql variant also got built. AFAIK +mysql for qt4-mac just adds some optional DB access classes to the library and builds a MySql driver for Qt to use. If variant names are indeed global, how would I avoid having every installed port that has variants +examples, +demos or +docs being re-installed? Variant selections are only global if you put them in the file /opt/local/etc/macports/variants.conf. Usually you don't do that; usually you just specify them on the command line, as in: sudo port install qt4-mac +mysql +quartz +examples +docs +demos Then those variants only apply to that port. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Exactly how do variants work?
On 05/05/2012, at 11:52 AM, Ryan Schmidt wrote: On May 4, 2012, at 20:45, Ian Wadham wrote: What port commands should I use to add a variant to an installed port? Do I need to uninstall and re-install the whole port? Yes, unfortunately that's how variants in MacPorts work. There's no distinction between variants that completely change how a port builds and those that just install extra files. Also, to what extent are variant names local or global? Variant selections are only global if you put them in the file /opt/local/etc/macports/variants.conf. Usually you don't do that; usually you just specify them on the command line, as in: sudo port install qt4-mac +mysql +quartz +examples +docs +demos Then those variants only apply to that port. Thanks very much, Ryan. Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gnuplot: question about wxWidgets(-devel) Universal variants
On 3/13/12 08:00 , macports-users-requ...@lists.macosforge.org wrote: Subject: Re: gnuplot: question about wxWidgets(-devel) Universal variants On Mon, Mar 12, 2012 at 01:46, Ryan Schmidt wrote: How exactly should the code be written to enable compiling 64-bit version of gnuplot with wxt terminal, without interfering with other ports and without breaking functionality for 32-bit architectures? Once/if that question is answered, I have a Portfile for the new gnuplot 4.6 ready to be committed. The simplest solution for us would be for the developers of wxWidgets to finally release a stable 64-bit compatible version of their software. Then we could update the wxWidgets portfile to that version and remove all the 32-bit forcing in all the ports that do that. However that probably won't happen for some time. Would it be acceptable for a non-default option of gnuplot to simply depend on wxWidgets-devel then? The version 2.9 also contains some nice features that are missing in 2.8, so it's not just about type of binary. (If necessary, there could be two options, one with wxWidgets and one with wxWidgets-devel, but I don't really think that two options are needed.) I tried to create an update at https://trac.macports.org/ticket/33596 wxWidgets and 64-bit has been a real PITA for some time now. The development series 2.9 has promise, but there are some problems. If you really need wxWidgets, I suggest using the X11/gtk backend. See this old ticket for a full explanation: http://trac.macports.org/ticket/24350 The variant for the 64-bit capable X11/gtk backend is available in the wxwidgets-python port. This could be translated to the regular wxwidgets port if someone is interested. I have stopped using wxwidgets due to these problems and am now using qt4. Jonathan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gnuplot: question about wxWidgets(-devel) Universal variants
On Tue, Mar 13, 2012 at 15:24, Jonathan Stickel wrote: wxWidgets and 64-bit has been a real PITA for some time now. The development series 2.9 has promise, but there are some problems. I would have asked what kind of problems, but I don't want to open a can of worms ;) At least it works for me for using a Gnuplot terminal. The old version (2.8) also works of course, but only for 32-bit applications and it lacks two nice features which is a bit painful. If you really need wxWidgets, I suggest using the X11/gtk backend. See this old ticket for a full explanation: I have no idea how to use X11/gtk backend, and since wxWidgets-devel also work (with Cocoa interface), I see no reason for including yet another alien into the game. But if that would simplify macports packaging and if somebody can show me how to do it, I have nothing against a working solution. I don't particularly like X11 thouh and there is already an X11 terminal available (with slightly less features), but if that's what it takes ... http://trac.macports.org/ticket/24350 I'm not sure that I understand all of what is written here. The variant for the 64-bit capable X11/gtk backend is available in the wxwidgets-python port. This could be translated to the regular wxwidgets port if someone is interested. I have stopped using wxwidgets due to these problems and am now using qt4. I would never develop a wxWidgets application myself, and even the author of wxWidgets code for gnuplot says that he is no longer interested in further maintainance (and that he would have written Qt code back then if he knew what he knows now). But since the code is there and application works now, it would be nice to support it as long as supporting is not too painful. The Portfile that I wrote (https://trac.macports.org/ticket/33596) seems to work, its only drawback is dependency on wxWidgets-devel and I'm not sure how that works on older macs. Gnuplot now also supports Qt terminal (which is not really polished out yet, at least not for the mac; printing semi-crashes, configuration is suboptimal and doesn't work out of the box), so Qt terminal is definitely an alternative. It would help if some knowledgable developer would fix a few mac-specific problems in gnuplot source code though (I can describe problems, but don't know how to solve them properly). I wouldn't have used MacPorts' gnuplot at all, but I don't know any other way if I want to use Octave. And AquaTerm is causing me serious problems (= it doesn't work at all), so I need at least one working terminal that's different from AquaTerm and both Qt and wxWidgets are good candidates that finally happen to work on mac in gnuplot 4.6. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gnuplot: question about wxWidgets(-devel) Universal variants
On 3/13/12 08:57 , Mojca Miklavec wrote: On Tue, Mar 13, 2012 at 15:24, Jonathan Stickel wrote: wxWidgets and 64-bit has been a real PITA for some time now. The development series 2.9 has promise, but there are some problems. I would have asked what kind of problems, but I don't want to open a can of worms ;) I have found that it is not compatible with Mayavi (a python visualization program), and I suspect the same for other projects that use wxwidgets. At least it works for me for using a Gnuplot terminal. The old version (2.8) also works of course, but only for 32-bit applications and it lacks two nice features which is a bit painful. If it works for you, great! If you really need wxWidgets, I suggest using the X11/gtk backend. See this old ticket for a full explanation: I have no idea how to use X11/gtk backend, and since wxWidgets-devel also work (with Cocoa interface), I see no reason for including yet another alien into the game. But if that would simplify macports packaging and if somebody can show me how to do it, I have nothing against a working solution. I don't particularly like X11 thouh and there is already an X11 terminal available (with slightly less features), but if that's what it takes ... Everything needed for the variant should be in the wxwidgets-python portfile. A simple copy of the relevant lines to the wxwidgets portfile should work OK. Some bug-squashing might be needed. But if wxwidgets-2.9 works for gnuplot, that does seem like a better solution than X11/gtk. http://trac.macports.org/ticket/24350 I'm not sure that I understand all of what is written here. The variant for the 64-bit capable X11/gtk backend is available in the wxwidgets-python port. This could be translated to the regular wxwidgets port if someone is interested. I have stopped using wxwidgets due to these problems and am now using qt4. I would never develop a wxWidgets application myself, and even the author of wxWidgets code for gnuplot says that he is no longer interested in further maintainance (and that he would have written Qt code back then if he knew what he knows now). But since the code is there and application works now, it would be nice to support it as long as supporting is not too painful. The Portfile that I wrote (https://trac.macports.org/ticket/33596) seems to work, its only drawback is dependency on wxWidgets-devel and I'm not sure how that works on older macs. Gnuplot now also supports Qt terminal (which is not really polished out yet, at least not for the mac; printing semi-crashes, configuration is suboptimal and doesn't work out of the box), so Qt terminal is definitely an alternative. It would help if some knowledgable developer would fix a few mac-specific problems in gnuplot source code though (I can describe problems, but don't know how to solve them properly). I wouldn't have used MacPorts' gnuplot at all, but I don't know any other way if I want to use Octave. And AquaTerm is causing me serious problems (= it doesn't work at all), so I need at least one working terminal that's different from AquaTerm and both Qt and wxWidgets are good candidates that finally happen to work on mac in gnuplot 4.6. I am facing similar problems with wx vs qt backends for matplotlib and mayavi in python. wx used to be the standard backend, but is being phased out (I think partly because of this painful transition from 2.8 to 2.9). Qt4 is the new preferred backend, but not all features work correctly. This has been an issue for over 2 years now. Hopefully things will get better over time. I have decided to got the Qt4 route and am dealing with the few issues. Jonathan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gnuplot: question about wxWidgets(-devel) Universal variants
On Mon, Mar 12, 2012 at 01:46, Ryan Schmidt wrote: How exactly should the code be written to enable compiling 64-bit version of gnuplot with wxt terminal, without interfering with other ports and without breaking functionality for 32-bit architectures? Once/if that question is answered, I have a Portfile for the new gnuplot 4.6 ready to be committed. The simplest solution for us would be for the developers of wxWidgets to finally release a stable 64-bit compatible version of their software. Then we could update the wxWidgets portfile to that version and remove all the 32-bit forcing in all the ports that do that. However that probably won't happen for some time. Would it be acceptable for a non-default option of gnuplot to simply depend on wxWidgets-devel then? The version 2.9 also contains some nice features that are missing in 2.8, so it's not just about type of binary. (If necessary, there could be two options, one with wxWidgets and one with wxWidgets-devel, but I don't really think that two options are needed.) I tried to create an update at https://trac.macports.org/ticket/33596 Mojca ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
gnuplot: question about wxWidgets(-devel) Universal variants
Hello,
I would like to use gnuplot with wxt terminal (wxWidgets). The current
Portfile uses
variant wxwidgets description Enable wxWidgets front-end {
depends_lib-append port:wxWidgets
configure.args-delete --disable-wxwidgets
configure.args-append --with-wx-config=${prefix}/bin/wx-config
}
if {[variant_isset wxwidgets]} {
# wxWidgets is not universal and is 32-bit only
universal_variant no
supported_archs i386 ppc
}
however wxWidgets 2.8 only support Carbon (= only ppc and i386). I
have tried to modify the gnuplot's Portfile to use wxWidgets 2.9. The
following code works for me (Lion x86_64):
variant wxwidgets description Enable wxWidgets front-end {
depends_lib-append port:wxWidgets-devel
configure.args-delete --disable-wxwidgets
configure.args-append --with-wx-config=${prefix}/bin/wx-config
}
if {[variant_isset wxwidgets]} {
if {${configure.compiler} == clang} {
configure.compiler llvm-gcc-4.2
}
}
but since many other ports depend on wxWidgets (conflicting with
wxWidgets-devel), it might be undesirable to put the code above to
gnuplot's Portfile. Also, for anyone using ppc or i386 the version 2.8
of wxWidgets might be perfectly OK.
How exactly should the code be written to enable compiling 64-bit
version of gnuplot with wxt terminal, without interfering with other
ports and without breaking functionality for 32-bit architectures?
Once/if that question is answered, I have a Portfile for the new
gnuplot 4.6 ready to be committed.
Thank you,
Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gnuplot: question about wxWidgets(-devel) Universal variants
On Mar 11, 2012, at 18:51, Mojca Miklavec wrote:
I would like to use gnuplot with wxt terminal (wxWidgets). The current
Portfile uses
variant wxwidgets description Enable wxWidgets front-end {
depends_lib-append port:wxWidgets
configure.args-delete --disable-wxwidgets
configure.args-append --with-wx-config=${prefix}/bin/wx-config
}
if {[variant_isset wxwidgets]} {
# wxWidgets is not universal and is 32-bit only
universal_variant no
supported_archs i386 ppc
}
however wxWidgets 2.8 only support Carbon (= only ppc and i386). I
have tried to modify the gnuplot's Portfile to use wxWidgets 2.9. The
following code works for me (Lion x86_64):
variant wxwidgets description Enable wxWidgets front-end {
depends_lib-append port:wxWidgets-devel
configure.args-delete --disable-wxwidgets
configure.args-append --with-wx-config=${prefix}/bin/wx-config
}
if {[variant_isset wxwidgets]} {
if {${configure.compiler} == clang} {
configure.compiler llvm-gcc-4.2
}
}
but since many other ports depend on wxWidgets (conflicting with
wxWidgets-devel), it might be undesirable to put the code above to
gnuplot's Portfile. Also, for anyone using ppc or i386 the version 2.8
of wxWidgets might be perfectly OK.
How exactly should the code be written to enable compiling 64-bit
version of gnuplot with wxt terminal, without interfering with other
ports and without breaking functionality for 32-bit architectures?
Once/if that question is answered, I have a Portfile for the new
gnuplot 4.6 ready to be committed.
The simplest solution for us would be for the developers of wxWidgets to
finally release a stable 64-bit compatible version of their software. Then we
could update the wxWidgets portfile to that version and remove all the 32-bit
forcing in all the ports that do that.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
port variants or different port
Hello, 1. I want to write a portfile for install the package auctex for emacs. I have two emacs installed, one is Emacs.app(Cocoa), the other is emacs(for non-graphical command line). Accordingly, I need to specify different configuration for auctex, i.e., set -with-emacs -with-lisp-dir to different locations. I want both Emacs.app and emacs can find the package auctex. In this case, should I write two different port files and give the port different names (auctex and auctex-app, for example) or should I make one portfile with two different variants? I try the latter, but it seems that only one variant is activated, that is, the lisp files only exist in one lisp-dir. Are there any other options I can use to make two variants activated at the same time? 2. How can I see the the definition of Portfiles for a particular port return by port search xxport? Thanks. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port variants or different port
On Jan 2, 2012, at 2:38 p.m., Shiyuan wrote:
1. I want to write a portfile for install the package auctex for emacs.
There's already a port called auctex, if you haven't seen it already.
I have two emacs installed, one is Emacs.app(Cocoa), the other is emacs(for
non-graphical command line). Accordingly, I need to specify different
configuration for auctex, i.e., set -with-emacs -with-lisp-dir to different
locations. I want both Emacs.app and emacs can find the package auctex. In
this case, should I write two different port files and give the port
different names (auctex and auctex-app, for example) or should I make one
portfile with two different variants? I try the latter, but it seems that
only one variant is activated, that is, the lisp files only exist in one
lisp-dir. Are there any other options I can use to make two variants
activated at the same time?
Variants are not mutually exclusive unless you define them to be. In this case,
AUCTeX's configure script might only accept one --with-lisp-dir argument and
one --with-emacs argument. Your best bet might be separate ports, or maybe
subports. I'm not familiar with what AUCTeX installs, so I can't say whether
separate ports would step on each other's toes by trying to install the same
files.
2. How can I see the the definition of Portfiles for a particular port
return by port search xxport?
You can print a portfile to stdout by using port cat portname or open it in
your default ${EDITOR} with port edit portname. For instance, to open the
portfile for emacs-app, use port edit emacs-app. Throw in an option to pick
your editor/viewer: port edit --editor vim emacs-app.
vq
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port variants or different port
On Mon, Jan 02, 2012 at 01:38:58PM -0600, Shiyuan wrote: 1. I want to write a portfile for install the package auctex for emacs. First, were you aware that there's already a port for auctex? I have two emacs installed, one is Emacs.app(Cocoa), the other is emacs(for non-graphical command line). Accordingly, I need to specify different configuration for auctex, i.e., set -with-emacs -with-lisp-dir to different locations. I want both Emacs.app and emacs can find the package auctex. Both emacs and emacs-app (as well as the other available emacsen) should be configured so that they'll look for lisp packages in /opt/local/share/emacs/site-lisp. Our elisp packages should probably all install there. In this case, should I write two different port files and give the port different names (auctex and auctex-app, for example) or should I make one portfile with two different variants? I try the latter, but it seems that only one variant is activated, that is, the lisp files only exist in one lisp-dir. Are there any other options I can use to make two variants activated at the same time? You can build a port with multiple variants selected but that probably wouldn't help you in this case. You can't have multiple installations of the port active at once, different variants or otherwise. You could probably do that with subports but I'm not sure that's the best approach here. 2. How can I see the the definition of Portfiles for a particular port return by port search xxport? `port file name` will print the path to the portfile; also, `port cat name` will print the contents. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
universal variants on Lion
I couldn't get TeXmacs to build on lion (OS 10.7.2), so I tried with the universal variant, and all of a sudden Macports started replacing other ports with their universal variant. Will this cause any problems down the road? -Mark ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: universal variants on Lion
On Dec 18, 2011, at 10:43 AM, mark brethen mbret...@aim.com wrote: I couldn't get TeXmacs to build on lion (OS 10.7.2), so I tried with the universal variant, and all of a sudden Macports started replacing other ports with their universal variant. Will this cause any problems down the road? Heh, happened to me as well. Took me by complete surprise. I control-c-ed it, and nothing seems to have gone wrong as of yet. Might be worthwhile to have an initial message come up explaining what is going to happen, with a default to no -Mark ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: universal variants on Lion
On Sun, Dec 18, 2011 at 10:43 AM, mark brethen mbret...@aim.com wrote: I couldn't get TeXmacs to build on lion (OS 10.7.2), so I tried with the universal variant, and all of a sudden Macports started replacing other ports with their universal variant. Will this cause any problems down the road? I think this is the expected behaviour. If you want the universal variant then all the deps must also be universal, so Macports installs them for you. The only problem is just that it will probably take longer to compile them. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: universal variants on Lion
Am 18.12.2011 um 16:43 schrieb mark brethen mbret...@aim.com: I couldn't get TeXmacs to build on lion (OS 10.7.2), so I tried with the universal variant, and all of a sudden Macports started replacing other ports with their universal variant. Will this cause any problems down the road? When something doesn't build on MacPorts don't start trying put variants without knowing what it does. Universal means (on Lion and SL) that MacPorts builds a 64 AND 32bit binary of the given port. Since the default on Lion is 64bit and that failed before you are very unlikely to get further with the universal variant. And since all dependencies need to be built universal as well you need to rebuilt every dependency in both arches (64 32 bit) as well. There might be trouble with ports that don't build in 32bit anymore. I encountered some before - don't know if they are still a problem (and I don't remember which anyway). Dom ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: universal variants on Lion
On Dec 18, 2011, at 10:18, Dominik Reichardt wrote: There might be trouble with ports that don't build in 32bit anymore. It would be a rare port indeed that can't build 32-bit; I don't know any offhand. Ports that can only build 32-bit, and cannot build 64-bit (usually because they use Carbon), are plentiful, however. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Dec 9, 2011, at 17:04, Chris Jones wrote: On 9 Dec 2011, at 10:34pm, Bradley Giesbrecht wrote: If the dependent port/variant combination installs different files you could check for their existence/non-existence. I have no idea. Seems rather messy … It is messy, but it is the only available option; sorry. On Dec 9, 2011, at 17:12, Chris Jones wrote: On 9 Dec 2011, at 10:50pm, Lawrence Velázquez wrote: See also: https://trac.macports.org/wiki/FAQ#dependonvariant Yes, I know about that. I just hoped there was some way to check if a certain variant of a port was installed or not. The purpose of the FAQ entry is to explain that that is not directly possible, sorry. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Dec 9, 2011, at 17:14, Scott Webster wrote: On Fri, Dec 9, 2011 at 2:23 PM, Chris Jones wrote: Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. This isn't exactly what you are asking for, but a similar idea: wine (and wine-devel) only builds 32 bit, so if you want to install it on a normally 64-bit system you need to make sure all the dependencies are build universal. MacPorts does so for you automatically, provided all dependencies were installed (or last upgraded) using MacPorts 1.9.0 or later. So, this information isn't relevant to this thread. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Sat, Dec 10, 2011 at 12:11 AM, Ryan Schmidt ryandes...@macports.org wrote: wine (and wine-devel) only builds 32 bit, so if you want to install it on a normally 64-bit system you need to make sure all the dependencies are build universal. MacPorts does so for you automatically, provided all dependencies were installed (or last upgraded) using MacPorts 1.9.0 or later. So, this information isn't relevant to this thread. Ok, well, good to know I guess. However, some of the rdeps of wine-devel are not installed universal on my clean Lion install. Interesting. Still seems to work. For instance gtk2. Hmm. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Dec 10, 2011, at 02:19, Scott Webster wrote: On Sat, Dec 10, 2011 at 12:11 AM, Ryan Schmidt wrote: wine (and wine-devel) only builds 32 bit, so if you want to install it on a normally 64-bit system you need to make sure all the dependencies are build universal. MacPorts does so for you automatically, provided all dependencies were installed (or last upgraded) using MacPorts 1.9.0 or later. So, this information isn't relevant to this thread. Ok, well, good to know I guess. However, some of the rdeps of wine-devel are not installed universal on my clean Lion install. Interesting. Still seems to work. For instance gtk2. Hmm. I can't explain that. That shouldn't be possible. wine-devel has a library dependency on gst-plugins-base which has a library dependency on gnome-vfs which has a library dependency on gconf which has a library dependency on gtk2. Except wine-devel, all of them have universal variants and none of them are 32-bit-only. If you originally installed them using MacPorts 1.9.0 or later, MacPorts should have upgraded them to universal when you installed wine-devel. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Sat, Dec 10, 2011 at 12:31 AM, Ryan Schmidt ryandes...@macports.org wrote: I can't explain that. That shouldn't be possible. wine-devel has a library dependency on gst-plugins-base which has a library dependency on gnome-vfs which has a library dependency on gconf which has a library dependency on gtk2. Except wine-devel, all of them have universal variants and none of them are 32-bit-only. If you originally installed them using MacPorts 1.9.0 or later, MacPorts should have upgraded them to universal when you installed wine-devel. My apologies. I have wine installed on this machine and not wine-devel, and it does not depend on gtk2, sorry! Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
warnings if dependencies don't have the correct variants ?
Hi, Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. The the last update to root I have disabled the opengl variant by default (previously enabled) because of this, but people upgrading are still running into problems. Chris smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Dec 9, 2011, at 2:23 PM, Chris Jones wrote: Hi, Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. The the last update to root I have disabled the opengl variant by default (previously enabled) because of this, but people upgrading are still running into problems. If the dependent port/variant combination installs different files you could check for their existence/non-existence. Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
See also: https://trac.macports.org/wiki/FAQ#dependonvariant vq On Dec 9, 2011, at 5:34 p.m., Bradley Giesbrecht wrote: On Dec 9, 2011, at 2:23 PM, Chris Jones wrote: Hi, Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. The the last update to root I have disabled the opengl variant by default (previously enabled) because of this, but people upgrading are still running into problems. If the dependent port/variant combination installs different files you could check for their existence/non-existence. Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On 9 Dec 2011, at 10:50pm, Lawrence Velázquez wrote: See also: https://trac.macports.org/wiki/FAQ#dependonvariant Yes, I know about that. I just hoped there was some way to check if a certain variant of a port was installed or not. In this case it seems, looking at the mesa variants, to be a one or other choice. No way to have both. mesa has the variants: iglx: Install a libGL that uses your X11 server's indirect GLX path for rendering (the default is off which allows libGL to accelerate rendering using OpenGL.framework) python26: Use python 2.6 * conflicts with python27 [+]python27: Use python 2.7 * conflicts with python26 universal: Build for multiple architectures So its X11 or OpenGl.framework, not both. Not sure I understand the logic of a port under x11/mesa not building by default with X11 support, but I'm sure there's a good reason (Seeing who the author of the Port is, I'm sure there is .. ;)) Chris vq On Dec 9, 2011, at 5:34 p.m., Bradley Giesbrecht wrote: On Dec 9, 2011, at 2:23 PM, Chris Jones wrote: Hi, Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. The the last update to root I have disabled the opengl variant by default (previously enabled) because of this, but people upgrading are still running into problems. If the dependent port/variant combination installs different files you could check for their existence/non-existence. Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On Fri, Dec 9, 2011 at 2:23 PM, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. This isn't exactly what you are asking for, but a similar idea: wine (and wine-devel) only builds 32 bit, so if you want to install it on a normally 64-bit system you need to make sure all the dependencies are build universal. The following command will spit out the list of dependencies that are NOT installed universal: port rdeps wine-devel | xargs port installed | grep -v 'universal' Anyway, I think I get that you are really asking for something like a port verifyvariants command, but if we had that we'd probably be able to have variant dependencies. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: warnings if dependencies don't have the correct variants ?
On 9 Dec 2011, at 11:12pm, Chris Jones wrote: On 9 Dec 2011, at 10:50pm, Lawrence Velázquez wrote: See also: https://trac.macports.org/wiki/FAQ#dependonvariant Yes, I know about that. I just hoped there was some way to check if a certain variant of a port was installed or not. In this case it seems, looking at the mesa variants, to be a one or other choice. No way to have both. mesa has the variants: iglx: Install a libGL that uses your X11 server's indirect GLX path for rendering (the default is off which allows libGL to accelerate rendering using OpenGL.framework) python26: Use python 2.6 * conflicts with python27 [+]python27: Use python 2.7 * conflicts with python26 universal: Build for multiple architectures So its X11 or OpenGl.framework, not both. Not sure I understand the logic of a port under x11/mesa not building by default with X11 support, but I'm sure there's a good reason (Seeing who the author of the Port is, I'm sure there is .. ;)) Turns out its the x11 variant of flew I need, not iglx in mesa. Same deal though, one or the other. glew has the variants: universal: Build for multiple architectures x11: Build libGLEW for GLX rather than OpenGL.framework Chris Chris vq On Dec 9, 2011, at 5:34 p.m., Bradley Giesbrecht wrote: On Dec 9, 2011, at 2:23 PM, Chris Jones wrote: Hi, Is it possible for a port to check if one of its dependencies is installed with a required variant, and warn if not ? I ask since the opengl variant of the root port requires mesa to be installed with the x11 variant, which is not the default. The build fails if this isn't the case. The the last update to root I have disabled the opengl variant by default (previously enabled) because of this, but people upgrading are still running into problems. If the dependent port/variant combination installs different files you could check for their existence/non-existence. Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
determining the exact variants that got installed
`port gdal` has a lot of variants. I installed it with several of those variants enabled. Is there a way to determine which all variants got installed? Here is why I ask -- I want to install a software (actually, PostGIS 2.0 development version, available from its SVN repo, not from MacPorts) that requires the Python bindings for GDAL. I installed gdal with its Python 2.7 variant, yet, the PostGIS configure script keeps on croaking saying I don't have the Python bindings installed. I am in a bind. -- Puneet Kishor ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
`port gdal` has a lot of variants. I installed it with several of those variants enabled. Is there a way to determine which all variants got installed? port -v installed gdal smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
On Sun, Oct 16, 2011 at 4:26 PM, Mr. Puneet Kishor punk.k...@gmail.com wrote: `port gdal` has a lot of variants. I installed it with several of those variants enabled. Is there a way to determine which all variants got installed? port installed gdal ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
On Oct 16, 2011, at 6:28 PM, Jeremy Lavergne wrote: `port gdal` has a lot of variants. I installed it with several of those variants enabled. Is there a way to determine which all variants got installed? port -v installed gdal Thanks. So... punkish@lucknow ~$port installed gdal The following ports are currently installed: gdal @1.8.0_0+expat gdal @1.8.0_1+curl+expat+geos+netcdf+postgresql90+python27+spatialite+sqlite3 (active) gdal @1.8.0_1+expat So, it seems I have multiple versions of gdal installed, and the PostGIS configure script is probably picking up the wrong version. Looking above, how do I uninstall `gdal @1.8.0_0+expat`. And, what is the difference between the next two? -- Puneet Kishor ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
$port installed gdal The following ports are currently installed: gdal @1.8.0_0+expat gdal @1.8.0_1+curl+expat+geos+netcdf+postgresql90+python27+spatialite+sqlite3 (active) gdal @1.8.0_1+expat So, it seems I have multiple versions of gdal installed, and the PostGIS configure script is probably picking up the wrong version. Looking above, how do I uninstall `gdal @1.8.0_0+expat`. And, what is the difference between the next two? Only one version is active, so the wrong versions cannot actually be picked up. Perhaps you have non-macports versions also installed? Either way, you can uninstall ambiguous port names by using the whole line that's printed from port installed: port uninstall gdal @1.8.0_1+expat smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
On Oct 16, 2011, at 6:35 PM, Jeremy Lavergne wrote: $port installed gdal The following ports are currently installed: gdal @1.8.0_0+expat gdal @1.8.0_1+curl+expat+geos+netcdf+postgresql90+python27+spatialite+sqlite3 (active) gdal @1.8.0_1+expat So, it seems I have multiple versions of gdal installed, and the PostGIS configure script is probably picking up the wrong version. Looking above, how do I uninstall `gdal @1.8.0_0+expat`. And, what is the difference between the next two? Only one version is active, so the wrong versions cannot actually be picked up. Perhaps you have non-macports versions also installed? Either way, you can uninstall ambiguous port names by using the whole line that's printed from port installed: port uninstall gdal @1.8.0_1+expat Thanks. That helped get rid of the inactive ports. Yet, my problem continues... ~$port installed gdal The following ports are currently installed: gdal @1.8.0_1+curl+expat+geos+netcdf+postgresql90+python27+spatialite+sqlite3 (active) $port content gdal Port gdal contains: .. /opt/local/bin/gdal-config .. punkish@Lucknow ~/Projects/postgis-svn$./configure --with-pgconfig=/opt/local/lib/postgresql90/bin/pg_config --with-gdalconfig=/opt/local/bin/gdal-config --with-geosconfig=/opt/local/bin/geos-config --with-raster --with-topology --with-projdir=/opt/local ... RASTER: Raster support requested checking for GDAL = 1.6.0... found checking for GDALFPolygonize in -lgdal... no checking for GDAL Python bindings... not found configure: error: GDAL Python bindings required by raster2pgsql.py loader rats. I am specifically requesting for the only gdal-config available. -- Puneet Kishor ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
I am specifically requesting for the only gdal-config available. You can manually run gdal-config; see what values it prints out for you. When you run it without argument it should tell you how to use it, then run it again requesting as much information as you can from it. smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: determining the exact variants that got installed
On Oct 16, 2011, at 6:47 PM, Jeremy Lavergne wrote: I am specifically requesting for the only gdal-config available. You can manually run gdal-config; see what values it prints out for you. Makes so much sense, and seems obvious, now that you have taught me how. Thanks! punkish@Lucknow /opt/local/bin$./gdal-config --dep-libs -L/opt/local/lib -lproj -L/opt/local/lib -lgeos_c -L/opt/local/lib -lexpat -L/opt/local -L/opt/local/lib -lgif -L/opt/local -L/opt/local/lib -ljpeg -L/opt/local/lib -lgeotiff -L/opt/local/lib -ltiff -L/opt/local -L/opt/local/lib -lpng -L/opt/local -L/opt/local/lib -lnetcdf -L/opt/local/lib/postgresql90 -lpq -lz -L/opt/local -L/opt/local/lib -lpthread -ldl -L/opt/local/lib -L/opt/local/lib -lspatialite -L/opt/local/lib -lcurl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lidn -lssl -lcrypto -lssl -lcrypto -lz -lz No mention of Python above. Yet, punkish@Lucknow /opt/local/bin$port installed gdal The following ports are currently installed: gdal @1.8.0_1+curl+expat+geos+netcdf+postgresql90+python27+spatialite+sqlite3 (active) Time to take this to the PostGIS list and ask how to specify/determine if Python bindings are installed. Many thanks Jeremy. When you run it without argument it should tell you how to use it, then run it again requesting as much information as you can from it. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Per package default variants
Hallo. Is there a way to pre-define variants, a certain package should or should not use? Eg. Let's say I'd want to build curl without ssl and with sftp_scp. All other packages should, by default, be built with ssl (if they support it). When manually installing the package, I'd run sudo port install curl -ssl +sftp_scp If I'd want to have all packages without ssl, I'd add -ssl to ~/.macports/variants.conf But that would effect all packages. Well, how to go about it? Thanks a lot, Alexander -- ↯ Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/ ↯ ↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: alexws77 ↯ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Per package default variants
On Sep 25, 2011, at 03:08, Alexander Skwar wrote: Is there a way to pre-define variants, a certain package should or should not use? Eg. Let's say I'd want to build curl without ssl and with sftp_scp. All other packages should, by default, be built with ssl (if they support it). When manually installing the package, I'd run sudo port install curl -ssl +sftp_scp If I'd want to have all packages without ssl, I'd add -ssl to ~/.macports/variants.conf But that would effect all packages. Well, how to go about it? This has been suggested before: https://trac.macports.org/ticket/30328 I still don't see the benefit of it. If you can explain, please do. But I don't see why you don't want to just run: sudo port install curl -ssl +sftp_scp In other words, the install command right there is how you specify that you want specific variants for a specific port. MacPorts will remember those selections across port upgrades. So the only time MacPorts would forget your selected variants is if you deliberately uninstall the port, but if you do that, doesn't that mean you're no longer interested in the port? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
variants
I'm wondering with Macports if it's possible when installing a port to specify a configure script argument that is not one of the list of variants that appears with that port? thanks ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: variants
On Wed, Mar 23, 2011 at 10:19 AM, Matthew Wallis matt...@worldaccent.com wrote: I'm wondering with Macports if it's possible when installing a port to specify a configure script argument that is not one of the list of variants that appears with that port? Probably the way to accomplish this is to create a custom repository of portfiles (likely containing only the single port you want to modify) and then edit the portfile to accomplish your desires. This is basically described in the Macports Guide. You could probably accomplish what you want in a slightly easier fashion, but it would then get wiped out whenever the port gets upgraded, so the custom repository method is required to accomplish what you want on a longer timescale. I could be wrong though. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: variants
On 2011-03-23 19:18 , Scott Webster wrote: Probably the way to accomplish this is to create a custom repository of portfiles (likely containing only the single port you want to modify) and then edit the portfile to accomplish your desires. This is basically described in the Macports Guide. [...] I could be wrong though. You are right. Here is the direct link to the guide: http://guide.macports.org/#development.local-repositories Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Requested variants do not match original selection +darwin
On Mar 13, 2011, at 11:33, Bruno DOUTRIAUX - Youmé-TECH wrote: i've got problems installing wxWidgets i've already tried port clean python27 mac-de-meriem-lentz:aMule-2.2.6 harlock59$ sudo port install wxWidgets Error: Requested variants do not match original selection +darwin. Please use the same variants again, perform 'port clean python27' or specify the force option (-f). Hmm. That original selection '+darwin' must have been made a very long time ago. MacPorts 1.9 doesn't record the +darwin variant in the registry anymore. Cleaning python27 should be all that's required to reset this. You're sure you've run sudo port clean python27 and it still occurs? You could also try cleaning all ports, just to be sure. selfupdate first to make sure you have the latest port definitions. sudo port selfupdate sudo port clean all ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 21:49, Dan Ports dpo...@macports.org wrote: Given that py26-gtk and py26-cairo depend on numpy, keeping build time down is quite a legitimate concern, so I too wonder whether -atlas ought to be the default. Atlas also seems to be the source of a lot of recent build issues with numpy. I've also found it to be temperamental when building on my new i5 MBP; in fact I've recently started build numpy with -atlas and scipy with +no_atlas (maybe they should be made consistent, but that's a topic for another thread). Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 11:51 PM, vincent habchi vi...@macports.org wrote: IMHO, the problem is not in numpy depending on Atlas, which is correct ; it is in other packages depending on numpy for tasks that may involve very little of it (e.g. using numpy as a convenient means to get array functions). Gimp relies ultimately on numpy for matrix convolutions in image processing, which can take quite a lot of time when the size of the image is large. Yeah, perhaps it is not so unreasonable for GIMP to pull in atlas (sorry if this is a bit tangential from the main point of this thread). Probably in an ideal world though you wouldn't need to build atlas/gcc etc. just to do some simple image cropping resizing etc though. But now that I've thought about it some more I'd probably choose to build atlas in order to get good image processing performance in GIMP. However, as you say, it would be nice to know what this is really achieving in terms of optimization. Perhaps it's huge, or perhaps it makes very little difference... I have no intuitive guess... Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 08:50:13PM +0100, Olaf Foellinger said: Hi, for quite some time I'm using macports now, main target is gnucash. Thanks for all the work and the support. Today I've noticed during an upgrade that macports tries to install atlas. That's because it's a standard dependency of py26-numpy. py26-numpy also adds gcc44 this way which is quite a lot for gnucash users. I would recommend to omit atlas from the default dependencies of p25-numpy. What do you think? Should I enter a ticket for this? Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: $ sudo port install py26-numpy -atlas If you're using the new sqlite format for the registry, this will be properly recorded but you won't see in in just a 'port installed'; you need to use verbose to see it: $ port -v installed py26-numpy The following ports are currently installed: py26-numpy @1.5.1_1-atlas (active) platform='darwin 10' archs='x86_64' Bryan Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 01:42:50PM -0700, Bryan Blackburn wrote: Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: Until now, I'd managed to be completely oblivious to the fact that atlas support was a variant in numpy. What are the drawbacks of building numpy without atlas? The advantages of not having to build atlas and gcc are obvious and considerable, at least to me. Given that py26-gtk and py26-cairo depend on numpy, keeping build time down is quite a legitimate concern, so I too wonder whether -atlas ought to be the default. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
Hi, * Bryan Blackburn b...@macports.org [14.02.11 21:42]wrote: Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: $ sudo port install py26-numpy -atlas that's clear. I've never installed it manually but using $ port install gnucash I haven't noticed that py26-numpy has installed atlas and gcc44 but recently I've tried to upgrade gnucash. Then I've noticed that atlas takes hours and hours to install. I think for the average gnucash user (and maybe for other ports that depends on py26-numpy) atlas is a heavy and not necessary dependency. atlas should be installed by users who explicitly select it. Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
Does this mean I don't really need atlas to use gimp either? On Mon, Feb 14, 2011 at 1:49 PM, Olaf Foellinger o...@foellinger.de wrote: Hi, * Bryan Blackburn b...@macports.org [14.02.11 21:42]wrote: Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: $ sudo port install py26-numpy -atlas that's clear. I've never installed it manually but using $ port install gnucash I haven't noticed that py26-numpy has installed atlas and gcc44 but recently I've tried to upgrade gnucash. Then I've noticed that atlas takes hours and hours to install. I think for the average gnucash user (and maybe for other ports that depends on py26-numpy) atlas is a heavy and not necessary dependency. atlas should be installed by users who explicitly select it. Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
