Re: Any objections to removal of the carbon variant in py-wxpython-2.8?
On Fri, Jan 17, 2014 at 3:14 AM, Ryan Schmidt wrote: On Jan 15, 2014, at 19:57, Eric Gallager wrote: On Wed, Jan 15, 2014 at 6:13 PM, Ryan Schmidt wrote: On Jan 15, 2014, at 10:27, Eric Gallager wrote: I am still on 10.6 and still use the `+carbon` variant for py-wxpython-2.8… Yes but would it be a problem for you to use the +gtk variant instead? If so please explain. No, just that I prefer it and currently use it... I could probably do without it though. Why do you prefer it? In what way is the carbon variant different from the gtk variant? I wasn't asked, but it's not difficult to imagine that users prefer the native GUI to X11 (while almost nobody cares if the app is 32-bit as long as that doesn't mean recompiling half of macports packages for several hours). Anyway, taking Eric's point into account, I decided to leave the +carbon variant (it doesn't hurt to have it if users want to use it for some reason), but to switch to +gtk as default even on 10.6 and to not actively support the +carbon variant in ports that depend on wxPython 2.8. Those users who really want to use Carbon-based wxPython will have to deal with problems related to that on their own. (If I try to use gtk2/3 +quartz, the majority of the ports doesn't work either.) That's enough to allow a reasonably simple and painless way of fixing ports that depend on wxPython. Also, if anyone has sufficient motivation to try to figure out how to make GTK-based wxWidgets work with +quartz to avoid X11, I'm willing to backport any future changes from trunk to 2.8.12. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Any objections to removal of the carbon variant in py-wxpython-2.8?
It just feels more Mac-native. Also it has a shorter dependency chain in that it does not drag in gtk, nor does it require that gtk be installed with the `+x11` variant. On Thu, Jan 16, 2014 at 9:14 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Jan 15, 2014, at 19:57, Eric Gallager wrote: On Wed, Jan 15, 2014 at 6:13 PM, Ryan Schmidt wrote: On Jan 15, 2014, at 10:27, Eric Gallager wrote: I am still on 10.6 and still use the `+carbon` variant for py-wxpython-2.8… Yes but would it be a problem for you to use the +gtk variant instead? If so please explain. No, just that I prefer it and currently use it... I could probably do without it though. Why do you prefer it? In what way is the carbon variant different from the gtk variant? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [116085] trunk/dports/science/demeter/Portfile
On Jan 17, 2014, at 16:49, macsforever2...@macports.org wrote: Revision 116085 Author macsforever2...@macports.org Date 2014-01-17 14:49:13 -0800 (Fri, 17 Jan 2014) Log Message demeter: Require perl 5.16. symlink main binaries into path. Modified Paths • trunk/dports/science/demeter/Portfile +require_active_variants \ +perl5 perl5_16 Shouldn’t you depend on perl5.16 instead of perl5 and ensure you’re using /opt/local/bin/perl5.16 instead of /opt/local/bin/perl? The symlinks installed by the perl5 port, like the symlinks installed by “port select”, are ideally intended for the user’s convenience, not something other ports should rely upon. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compilers and MPI Port Groups
s...@macports.org writes: s...@macports.org writes: Hello all and Happy Boxing Day! I have done a complete rewrite of the compilers and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those that want to know more. Highlights: - specify which compilers to set via compilers.choose, e.g. 'compilers.choose f77 f90 fc' - functions for testing if fortran has been selected for optional interfaces - portfile author can specify if fortran (or mpi) is required - unified and have made non-conflicting openmpi and mpich ports; also added an openmpi-devel port [1] - can now select either mpi port as the default mpi installation Example of a portfile using the new compilers portgroup: https://smf.io/macports/changeset/compilers Example of a portfile that uses the mpi portgroup: https://smf.io/macports/files/mpi/dports/science/hdf5-18/Portfile The changes I made to the sparskit and hdf5-18 portfiles are just examples I did for illustrative purposes. I won't push them unless the portfile author wants it. The mpich and openmpi portfiles need these changes so that the mpi portgroup will work. Anyway, I'd like to push this soon so that I can continue other work (and close a lot of tickets), so it'd be great if others could take a look at the proposed changes. [1] https://smf.io/macports/changeset/81bb51 or look at the changelog https://smf.io/macports/changelog to see all the diffs Just an update to say that I've gone ahead and finished updating all the ports that use mpi to use this new port group. The only work that needs to be done is to get some review of this patch series and after that, permission to push. I've cc'd the people who are the maintainers of the ports I changed, listed below. It'd be great to have you guys look at the changes. dstrubbe: sparskit, hpl, octopus eborisch: mpich mww: openmpi raimue: valgrind, valgrind-devel takeshi: berkeley_upc, omnixmp, gnudatalanguage, netcdf, netcdf-cxx, netcdf-cxx4, netcdf-fortran mmoll: optpp, hdf5-18, arpack hum: plda howarth: apbs-mpi mattoates: raxml mk: scotch michaelld: SuiteSparse Check out http://smf.io/macports for the updated changes. Having other people look at this would be great and hopefully would catch some of the errors I missed. The common ones I noticed were missing revbumps (though, I think I got all of those now). Documentation is very much read the comments and the code itself or look at an example so, apologies about that. Also, sometimes I couldn't think of a good name for a proc, so if anyone has a better name, please speak up. Some changes since last email are: - ensure the same mpi is used via mpi.enforce_variant - ensure the same c compiler is used (even when using mpi) via compilers.enforce_c - similar for fortran, compilers.enforce_fortran - test for avx compatible compiler via avx_variant_isset Still yet to be done is to replace all custom recipes done for the compiler variants. By my count, there are no more than 72 of those ports. This is lower priority since they'll still work as is. If nobody has any objections to this, I was hoping to push this in a few days. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
