How to call the compiler as if it were the linker
On Oct 2, 2014, at 12:59 AM, ryandes...@macports.org wrote:
> Revision
> 126021
> Author
> ryandes...@macports.org
> Date
> 2014-10-01 22:59:21 -0700 (Wed, 01 Oct 2014)
> Log Message
>
> gr1c: new port, version 0.6.2 (#41653)
> Added Paths
>
> • trunk/dports/math/gr1c/
> • trunk/dports/math/gr1c/Portfile
> • trunk/dports/math/gr1c/files/
> • trunk/dports/math/gr1c/files/patch-Makefile.diff
> • trunk/dports/math/gr1c/files/patch-tests-Makefile.diff
> +build.args CC="${configure.cc} [get_canonical_archflags cc]" \
> +LD="${configure.cc} [get_canonical_archflags ld] -r" \
This port's Makefile sets:
> CC = gcc
> LD = ld -r
ld is designed to produce output in a single architecture only, so that doesn't
work for universal builds. But when the compiler calls ld, it does so once for
each architecture, then "lipo"s the results together.
I thought I would be clever and just replace "ld" with ${configure.cc} and that
would work, and it did on Yosemite beta. On every previous system however it
caused clang to experience an assertion failure, so I must not be doing this
right.
What is the right way to invoke clang or gcc as if it were ld so that it does
the multiple-ld-and-lipo dance for me?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [126005] trunk/dports/mail/dovecot2/Portfile
> On Oct 1, 2014, at 4:10 PM, pixi...@macports.org wrote:
>
> Revision
> 126005
> Author
> pixi...@macports.org
> Date
> 2014-10-01 14:10:50 -0700 (Wed, 01 Oct 2014)
> Log Message
>
> mail/dovecot2:
> - Replace hardcoded /opt/local the $prefix.
> - Remove trailing whitespace.
>
> Modified Paths
>
> • trunk/dports/mail/dovecot2/Portfile
> -configure.cppflags-append -I/opt/local/include -I/opt/local/lib
> -configure.ldflags-append-L/opt/local/lib/
> +configure.cppflags-append -I${prefix}/include -I${prefix}/lib
> +configure.ldflags-append-L${prefix}/lib/
Why append -I${prefix}/include to configure.cppflags? It's there by default,
except that you've overridden configure.cppflags earlier in the portfile, but
why?
Why append -I${prefix}/lib to configure.cppflags? There are no include files in
${prefix}/lib.
Why append -L${prefix}/lib/ to configure.ldflags? -L${prefix}/lib is already in
configure.ldflags and is equivalent.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Oct 1, 2014, at 1:59 PM, Bradley Giesbrecht wrote: > > On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote: > >> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: >> >>> The problem with dots in port names is that so far "port lint" has declared >>> the dot an illegal character in a variant name. This has led the perl5 port >>> for example to adopt variant names like perl5_16 which I've always found a >>> little confusing. It has been nice that under the original naming scheme, >>> one could assume that in many cases the variant name matches the name of >>> the dependency that will be added. If you want to use the python27 port, >>> you use a port's +python27 variant, etc. >>> >>> Leaving the dot in would remove the ambiguity, as demonstrated by the Perl >>> ports, and "port lint" may be overly cautious in its prohibition of the dot >>> in variant names. Someone should do some tests. Make variants with dots, >>> like "mysql5.1", and see if they work correctly. Can you install the port? >>> Can you upgrade the port? Can you uninstall the port? What if other >>> variants are also selected? If everything works fine we can relax this lint >>> restriction. >> >> A cursory glance at port.tcl suggests that periods are acceptable in variant >> names. >> >> http://trac.macports.org/browser/tags/release_2_3_1/base/src/port/port.tcl#L287 > > Lint warnings aside, after adding a mariadb10.0 variant to sphinx I have been > able to install, activate and deactivate sphinx with an assortment of > variants including mariadb10.0. Lint warning gone after adding a "." to the regex on variantname: http://trac.macports.org/browser/tags/release_2_3_1/base/src/port1.0/portlint.tcl#L411 Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Oct 1, 2014, at 1:10 PM, Lawrence Velázquez wrote: > On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: > >> The problem with dots in port names is that so far "port lint" has declared >> the dot an illegal character in a variant name. This has led the perl5 port >> for example to adopt variant names like perl5_16 which I've always found a >> little confusing. It has been nice that under the original naming scheme, >> one could assume that in many cases the variant name matches the name of the >> dependency that will be added. If you want to use the python27 port, you use >> a port's +python27 variant, etc. >> >> Leaving the dot in would remove the ambiguity, as demonstrated by the Perl >> ports, and "port lint" may be overly cautious in its prohibition of the dot >> in variant names. Someone should do some tests. Make variants with dots, >> like "mysql5.1", and see if they work correctly. Can you install the port? >> Can you upgrade the port? Can you uninstall the port? What if other variants >> are also selected? If everything works fine we can relax this lint >> restriction. > > A cursory glance at port.tcl suggests that periods are acceptable in variant > names. > > http://trac.macports.org/browser/tags/release_2_3_1/base/src/port/port.tcl#L287 Lint warnings aside, after adding a mariadb10.0 variant to sphinx I have been able to install, activate and deactivate sphinx with an assortment of variants including mariadb10.0. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125999] trunk/dports/science/ifeffit/Portfile
On Oct 1, 2014, at 2:47 PM, Ryan Schmidt wrote:
>
>> On Oct 1, 2014, at 2:02 PM, m...@macports.org wrote:
>>
>> Revision
>> 125999
>> Author
>> m...@macports.org
>> Date
>> 2014-10-01 12:02:07 -0700 (Wed, 01 Oct 2014)
>> Log Message
>>
>> ifeffit: Only use gcc for FORTRAN. (#44631)
>> Modified Paths
>>
>> • trunk/dports/science/ifeffit/Portfile
>>
>
>
>> -if {![variant_isset gcc45] && ![variant_isset gcc46] && ![variant_isset
>> gcc47] && ![variant_isset gcc48]} {
>> -default_variants+gcc49
>>
>> +if {![variant_isset gcc45] && ![variant_isset gcc46] && ![variant_isset
>> gcc47] && ![variant_isset gcc49]} {
>> +default_variants+gcc48
>
> Why not default to gcc49?
>
> https://lists.macosforge.org/pipermail/macports-dev/2014-September/028119.html
I’m waiting for agreement with other science port maintainers to move forward
on gcc49 as default. gcc48 is still the Macports default gfortran compiler. As
I stated in another thread, I think it best if we migrate to the compilers
portgroup and change it there.
The only reason it was set to gcc49 was because it was causing an error when
compiling p5.16-ifeffit when gcc48 was used.
Cheers!
Frank
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125999] trunk/dports/science/ifeffit/Portfile
> On Oct 1, 2014, at 2:02 PM, m...@macports.org wrote:
>
> Revision
> 125999
> Author
> m...@macports.org
> Date
> 2014-10-01 12:02:07 -0700 (Wed, 01 Oct 2014)
> Log Message
>
> ifeffit: Only use gcc for FORTRAN. (#44631)
> Modified Paths
>
> • trunk/dports/science/ifeffit/Portfile
>
> -if {![variant_isset gcc45] && ![variant_isset gcc46] && ![variant_isset
> gcc47] && ![variant_isset gcc48]} {
> -default_variants+gcc49
>
> +if {![variant_isset gcc45] && ![variant_isset gcc46] && ![variant_isset
> gcc47] && ![variant_isset gcc49]} {
> +default_variants+gcc48
Why not default to gcc49?
https://lists.macosforge.org/pipermail/macports-dev/2014-September/028119.html
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: > The problem with dots in port names is that so far "port lint" has declared > the dot an illegal character in a variant name. This has led the perl5 port > for example to adopt variant names like perl5_16 which I've always found a > little confusing. It has been nice that under the original naming scheme, one > could assume that in many cases the variant name matches the name of the > dependency that will be added. If you want to use the python27 port, you use > a port's +python27 variant, etc. > > Leaving the dot in would remove the ambiguity, as demonstrated by the Perl > ports, and "port lint" may be overly cautious in its prohibition of the dot > in variant names. Someone should do some tests. Make variants with dots, like > "mysql5.1", and see if they work correctly. Can you install the port? Can you > upgrade the port? Can you uninstall the port? What if other variants are also > selected? If everything works fine we can relax this lint restriction. A cursory glance at port.tcl suggests that periods are acceptable in variant names. http://trac.macports.org/browser/tags/release_2_3_1/base/src/port/port.tcl#L287 vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
On Oct 1, 2014, at 3:30 PM, Sean Farley wrote: > Lawrence Velázquez writes: > >> Except that base automatically adds dependencies on `gccXY` depending on >> configure.compiler, so renaming them requires some sort of migration >> strategy. Either we wait until a new MacPorts release, or we jury-rig some >> sort of stub-port thing. > > I think we'll have to have a stub-port thing to help users upgrade? Yeah. The only difference I can see would be that if we synchronized with a base release, we would mark the stub ports as obsolete. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
Lawrence Velázquez writes: > Resurrecting this thread. Let's keep general renaming discussion here. Sure, sounds good. > On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: > >> It's been proposed on this list that we should rename MySQL ports e.g. >> mysql51 -> mysql-5.1; this would be to match the existing new ports >> mariadb-10.0 and mariadb-10.1. Consistency is good, especially within a >> particular type of software (e.g. MySQL in this case) but renaming MySQL >> ports is more problematic than renaming most ports, because MySQL ports are >> database servers and users may have databases and config files in their >> default version-specific directories which the user would manually have to >> move. > > Consistency is good, but I'd argue not especially critical. If migrating a > particular port or set of ports would be too much work, it would not be the > end of the world if we left it/them. > > Consistency of variant names is probably more important than consistency of > port names, since it affects variant inheritance. This is an important point, thanks. >> The problem with dashes in port names is that a dash is not a legal >> character in a variant name because it is confused with the syntax for >> disabling a variant, and often when there are multiple versions of a port, >> other ports will want to reference those multiple versions in corresponding >> variants. > > True, but we already have tons of ports with hyphens in their names. It seems > odd to me to use hyphens in some places (e.g., `py34-requests`) but avoid > them in others (`gcc49`). Very much agreed. >> The problem with dots in port names is that so far "port lint" has declared >> the dot an illegal character in a variant name. This has led the perl5 port >> for example to adopt variant names like perl5_16 which I've always found a >> little confusing. It has been nice that under the original naming scheme, >> one could assume that in many cases the variant name matches the name of the >> dependency that will be added. If you want to use the python27 port, you use >> a port's +python27 variant, etc. > > Matching variants and dependencies is certainly nice, but I don't think we > should get hung up on it, since the dependencies are added automatically. I > personally would be entirely fine with `+gcc4.9` pulling in `gcc-4.9`, and I > think the hyphenated port names look cleaner. This is entirely subjective, of > course. > >> The only disadvantage I see to the old naming scheme is ambiguity when a >> version number component reaches two digits, e.g. is the scala210 port >> version 2.1.0 or 2.10? (It's 2.10.) Is the ruby186 port version 1.8.6 or >> 1.86? (It's 1.8.6 -- perhaps this port should have been named ruby18 >> instead.) Leaving the dot in would remove the ambiguity, as demonstrated by >> the Perl ports, and "port lint" may be overly cautious in its prohibition of >> the dot in variant names. Someone should do some tests. Make variants with >> dots, like "mysql5.1", and see if they work correctly. Can you install the >> port? Can you upgrade the port? Can you uninstall the port? What if other >> variants are also selected? If everything works fine we can relax this lint >> restriction. > > I haven't done any tests, but I'd much prefer adding the periods, if possible. I agree with this, too. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
Frank Schima writes: > On Oct 1, 2014, at 12:26 PM, Sean Farley wrote: > >> Ryan Schmidt writes: >> >>> On Oct 1, 2014, at 12:48 PM, Sean Farley wrote: >>> Proposal: Since it seems that we are flat-out disallowing gcc being used as a C/C++ compiler, I think it's time to do some clean up of the code: 1) Rename gccXY to gcc-X.Y >>> >>> As I proposed earlier, we might want to avoid using a dash in a port name, >>> because it is nice to have the port name and variant name be the same, >>> therefore I proposed gccX.Y instead of gcc-X.Y. However, renaming existing >>> ports is a pain, and going forward new versions of gcc starting with gcc5 >>> will just have a single major version number so no change would be >>> necessary there. >> >> We really should be consistent then. I personally don't care what the >> new name is but we should either have clangX.Y / gccX.Y or clangXY / >> gccXY. > > I say we use gccX.Y. Just renaming gcc ports (for now) won’t be too hard. Sure, that's fine, we just all need to decide on something. >> 2) Rename +gccXY variants to +gfortranXY > > Sounds good to me, though we should use +gfortranX.Y if we switch the gcc > ports to gccX.Y. Yep, agreed. >> 3) Start moving away from configure.compiler=macports-gcc* > > This seems like a good idea. In fact, that made me realize what I was doing > wrong in #44631. :-) > We should move all ports with gccXY variants to the compilers portgroup. This is one of my goals. Having this logic in one place would cut down on a lot of code duplication and unexpected behavior. > Sean, I hereby give you permission to fix all of my ports (ifeffit, py-qutip, > py-usadel1 at least). Once all or most ports use it, then maybe we can switch > to gcc49 (really gfortran4.9) as Ryan proposed earlier. That would be a great benefit of everything using one port group for this: easily changing the default gfortran for all ports. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Recommendations for version numbers in port names
Resurrecting this thread. Let's keep general renaming discussion here. On Sep 16, 2014, at 5:22 PM, Ryan Schmidt wrote: > It's been proposed on this list that we should rename MySQL ports e.g. > mysql51 -> mysql-5.1; this would be to match the existing new ports > mariadb-10.0 and mariadb-10.1. Consistency is good, especially within a > particular type of software (e.g. MySQL in this case) but renaming MySQL > ports is more problematic than renaming most ports, because MySQL ports are > database servers and users may have databases and config files in their > default version-specific directories which the user would manually have to > move. Consistency is good, but I'd argue not especially critical. If migrating a particular port or set of ports would be too much work, it would not be the end of the world if we left it/them. Consistency of variant names is probably more important than consistency of port names, since it affects variant inheritance. > The problem with dashes in port names is that a dash is not a legal character > in a variant name because it is confused with the syntax for disabling a > variant, and often when there are multiple versions of a port, other ports > will want to reference those multiple versions in corresponding variants. True, but we already have tons of ports with hyphens in their names. It seems odd to me to use hyphens in some places (e.g., `py34-requests`) but avoid them in others (`gcc49`). > The problem with dots in port names is that so far "port lint" has declared > the dot an illegal character in a variant name. This has led the perl5 port > for example to adopt variant names like perl5_16 which I've always found a > little confusing. It has been nice that under the original naming scheme, one > could assume that in many cases the variant name matches the name of the > dependency that will be added. If you want to use the python27 port, you use > a port's +python27 variant, etc. Matching variants and dependencies is certainly nice, but I don't think we should get hung up on it, since the dependencies are added automatically. I personally would be entirely fine with `+gcc4.9` pulling in `gcc-4.9`, and I think the hyphenated port names look cleaner. This is entirely subjective, of course. > The only disadvantage I see to the old naming scheme is ambiguity when a > version number component reaches two digits, e.g. is the scala210 port > version 2.1.0 or 2.10? (It's 2.10.) Is the ruby186 port version 1.8.6 or > 1.86? (It's 1.8.6 -- perhaps this port should have been named ruby18 > instead.) Leaving the dot in would remove the ambiguity, as demonstrated by > the Perl ports, and "port lint" may be overly cautious in its prohibition of > the dot in variant names. Someone should do some tests. Make variants with > dots, like "mysql5.1", and see if they work correctly. Can you install the > port? Can you upgrade the port? Can you uninstall the port? What if other > variants are also selected? If everything works fine we can relax this lint > restriction. I haven't done any tests, but I'd much prefer adding the periods, if possible. > And I don't want to take on massive port renaming efforts for the sake of the > formatting of a version number. I don't plan to change the PHP ports and the > almost 100 PHP modules and the dozen ports that have PHP variants, and I'll > bet nobody wants to take on changing the Python ports and the almost 1000 > Python modules and hundreds of ports with Python variants. Remember it would > not only be the work of renaming all the ports, but also developing an > upgrade strategy to help all the existing users of the ports under their > current names. It would be a lot of work, but it doesn't have to happen all at once, in a short period of time. Or, again, we could just focus on renaming variants. Consistency of port names is rather less important. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
Lawrence Velázquez writes: > On Oct 1, 2014, at 3:08 PM, Frank Schima wrote: > >> On Oct 1, 2014, at 12:26 PM, Sean Farley wrote: >> >>> We really should be consistent then. I personally don't care what the >>> new name is but we should either have clangX.Y / gccX.Y or clangXY / >>> gccXY. >> >> I say we use gccX.Y. Just renaming gcc ports (for now) won’t be too hard. > > Except that base automatically adds dependencies on `gccXY` depending on > configure.compiler, so renaming them requires some sort of migration > strategy. Either we wait until a new MacPorts release, or we jury-rig some > sort of stub-port thing. I think we'll have to have a stub-port thing to help users upgrade? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
On Oct 1, 2014, at 3:08 PM, Frank Schima wrote: > On Oct 1, 2014, at 12:26 PM, Sean Farley wrote: > >> We really should be consistent then. I personally don't care what the >> new name is but we should either have clangX.Y / gccX.Y or clangXY / >> gccXY. > > I say we use gccX.Y. Just renaming gcc ports (for now) won’t be too hard. Except that base automatically adds dependencies on `gccXY` depending on configure.compiler, so renaming them requires some sort of migration strategy. Either we wait until a new MacPorts release, or we jury-rig some sort of stub-port thing. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
On Oct 1, 2014, at 12:26 PM, Sean Farley wrote: > Ryan Schmidt writes: > >> On Oct 1, 2014, at 12:48 PM, Sean Farley wrote: >> >>> Proposal: >>> >>> Since it seems that we are flat-out disallowing gcc being used as a >>> C/C++ compiler, I think it's time to do some clean up of the code: >>> >>> 1) Rename gccXY to gcc-X.Y >> >> As I proposed earlier, we might want to avoid using a dash in a port name, >> because it is nice to have the port name and variant name be the same, >> therefore I proposed gccX.Y instead of gcc-X.Y. However, renaming existing >> ports is a pain, and going forward new versions of gcc starting with gcc5 >> will just have a single major version number so no change would be necessary >> there. > > We really should be consistent then. I personally don't care what the > new name is but we should either have clangX.Y / gccX.Y or clangXY / > gccXY. I say we use gccX.Y. Just renaming gcc ports (for now) won’t be too hard. > 2) Rename +gccXY variants to +gfortranXY Sounds good to me, though we should use +gfortranX.Y if we switch the gcc ports to gccX.Y. > 3) Start moving away from configure.compiler=macports-gcc* This seems like a good idea. In fact, that made me realize what I was doing wrong in #44631. We should move all ports with gccXY variants to the compilers portgroup. Sean, I hereby give you permission to fix all of my ports (ifeffit, py-qutip, py-usadel1 at least). Once all or most ports use it, then maybe we can switch to gcc49 (really gfortran4.9) as Ryan proposed earlier. Thank you taking this on. Cheers! -Frank ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Drop PPC support
Bradley Giesbrecht writes: > On Oct 1, 2014, at 10:58 AM, Sean Farley wrote: > >> As discussed in the MPI thread, PPC is very old and is causing quite the >> development burden. I would be in favor of discussing how much effort we >> really want to spend supporting them (similar to supporting libstdc++ on >> Mavericks). >> >> We could tag some known version of the MacPorts svn tree for PPC users >> and be done with it. This would allow us to concentrate on other issues. >> >> We could also talk about how far of an OS back do we really want to >> support. Tiger and Leopard are decrepit. We don't even have buildbots >> for PPC nor OSes below Lion. > > There are buildbots for Snow Leopard. > https://build.macports.org/buildslaves Whoops, I missed that. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
Ryan Schmidt writes: > On Oct 1, 2014, at 12:48 PM, Sean Farley wrote: > >> Proposal: >> >> Since it seems that we are flat-out disallowing gcc being used as a >> C/C++ compiler, I think it's time to do some clean up of the code: >> >> 1) Rename gccXY to gcc-X.Y > > As I proposed earlier, we might want to avoid using a dash in a port name, > because it is nice to have the port name and variant name be the same, > therefore I proposed gccX.Y instead of gcc-X.Y. However, renaming existing > ports is a pain, and going forward new versions of gcc starting with gcc5 > will just have a single major version number so no change would be necessary > there. We really should be consistent then. I personally don't care what the new name is but we should either have clangX.Y / gccX.Y or clangXY / gccXY. >> 2) Rename +gccXY variants to +gfortranXY > > Note that some ports use gcc variants not for fortran support but for java > support. I'm thinking here of my much-neglected pdftk port, though for that I > may just remove the variants and use a single known-good java compiler. I think the name of the compiler would be more appropriate. In this case, +gcjXY. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Drop PPC support
On Oct 1, 2014, at 10:58 AM, Sean Farley wrote: > As discussed in the MPI thread, PPC is very old and is causing quite the > development burden. I would be in favor of discussing how much effort we > really want to spend supporting them (similar to supporting libstdc++ on > Mavericks). > > We could tag some known version of the MacPorts svn tree for PPC users > and be done with it. This would allow us to concentrate on other issues. > > We could also talk about how far of an OS back do we really want to > support. Tiger and Leopard are decrepit. We don't even have buildbots > for PPC nor OSes below Lion. There are buildbots for Snow Leopard. https://build.macports.org/buildslaves Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Renaming GCC ports and variants
On Oct 1, 2014, at 12:48 PM, Sean Farley wrote: > Proposal: > > Since it seems that we are flat-out disallowing gcc being used as a > C/C++ compiler, I think it's time to do some clean up of the code: > > 1) Rename gccXY to gcc-X.Y As I proposed earlier, we might want to avoid using a dash in a port name, because it is nice to have the port name and variant name be the same, therefore I proposed gccX.Y instead of gcc-X.Y. However, renaming existing ports is a pain, and going forward new versions of gcc starting with gcc5 will just have a single major version number so no change would be necessary there. > 2) Rename +gccXY variants to +gfortranXY Note that some ports use gcc variants not for fortran support but for java support. I'm thinking here of my much-neglected pdftk port, though for that I may just remove the variants and use a single known-good java compiler. > 3) Start moving away from configure.compiler=macports-gcc* We started this already last year when Mavericks was released. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts-MySQL Dictator wanted, prefer benevolent
On Oct 1, 2014, at 6:45 AM, Craig Treleaven wrote:
> At 3:07 PM -0500 9/30/14, Ryan Schmidt wrote:
>> Currently, the latest stable version of MariaDB is 10.0.
>
> Really?
Yes, in that MariaDB 10.0 is the latest "release" version.
> Has MariaDB 10.0 really been sufficiently exercised in the
> OS X environment to become the default? Currently, not a single port
> that I've identified even offers mariadb-10.0 as a variant. Only 4
> ports in my list currently default to mariadb or mariadb55:
>
> PortDefault Variant
> akonadi mariadb55
> amarok mariadb55
> py24-mysql mariadb55
> py25-mysql mariadb55
> py26-mysql mariadb55
> py27-mysql mariadb55
> qore-mysql-module mariadb
As soon as the variant naming is settled there will be mariadb-10.{0,1}
variants.
>> The question is what to name the variants. This has also been
>> brought up for discussion before. My most recent thread on the topic
>> from 2 weeks ago got no replies on the list; perhaps I was too wordy.
>>
>> My suggestion was that using dots in version numbers, but no
>> underscores, would be the cleanest and most informative, which would
>> make the complete list of proposed MySQL variant today: +mariadb5.5,
>> +mariadb10.0, +mariadb10.1, +mysql5.1, +mysql5.5, +mysql5.6, and
>> +percona5.6.
>
> Adopting this format means renaming every variant of every affected port.
>
> This may also break the upgrade path for existing installs, no? We
> really should keep legacy-named variants for a period of time along
> with the new standard which leads to an explosion of variants for
> some ports.
I think it is common to add something like this for a time (1 year):
if [variant_isset ${legacy-variant}] {
default_variants-append +${replacement-variant}
}
> For example, apr-util currently has mariadb, mysql5,
> mysql51, mysql55, mysql56, and percona variants related to db
> selection. We'd have to keep those 6 and add at least 6 more (maybe
> 8 if maridb10.0 and mariadb10.1 are supported).
Similar to recent discussions regarding removing old versions of perl and
python, we should consider removing/replacing older versions of mysql like
mysql4 and mysql5 and probably mysql51.
I believe it would be an improvement if we settled on these ports for now and
removed/replace all others:
mariadb-5.5 // MariaDB has long term support contract with Redhat for this 5.5
mariadb-10.0 // Newest stable release
mariadb-10.1 // Alpha release
mysql-5.5
mysql-5.6 // Generally Available (GA) Release
mysql-5.7 // Development Release
percona-5.5
percona-5.6
https://downloads.mariadb.org/mariadb/+releases/
http://dev.mysql.com/downloads/mysql/
http://www.percona.com/downloads/
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Drop PPC support
On Oct 1, 2014, at 12:01 PM, Daniel J. Luke wrote: > On Oct 1, 2014, at 1:58 PM, Sean Farley wrote: >> >> As discussed in the MPI thread, PPC is very old and is causing quite the >> development burden. I would be in favor of discussing how much effort we >> really want to spend supporting them (similar to supporting libstdc++ on >> Mavericks). >> >> We could tag some known version of the MacPorts svn tree for PPC users >> and be done with it. This would allow us to concentrate on other issues. >> >> We could also talk about how far of an OS back do we really want to >> support. Tiger and Leopard are decrepit. We don't even have buildbots >> for PPC nor OSes below Lion. >> >> Should we finally drop some of this older stuff? >> >> Comments welcomed. > > Historically we officially support the current and previous Mac OS X release > (while not doing anything to on-purpose break older releases / being willing > to accept patches to make things work on older releases). > > I think that's a reasonable policy. > > We have made some effort to support PPC machines for a while longer than > that, which was nice, but we probably shouldn't be doing anymore. > > I don't think we should provide installers/builds for anything other than the > supported Mac OS X releases - and I also think we should make sure we're only > supporting OS releases that are currently getting security updates from > upstream… +1 It’s long overdue that we drop support for legacy (not supported by Apple) systems. -Frank ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Drop PPC support
On Oct 1, 2014, at 1:58 PM, Sean Farley wrote: > > As discussed in the MPI thread, PPC is very old and is causing quite the > development burden. I would be in favor of discussing how much effort we > really want to spend supporting them (similar to supporting libstdc++ on > Mavericks). > > We could tag some known version of the MacPorts svn tree for PPC users > and be done with it. This would allow us to concentrate on other issues. > > We could also talk about how far of an OS back do we really want to > support. Tiger and Leopard are decrepit. We don't even have buildbots > for PPC nor OSes below Lion. > > Should we finally drop some of this older stuff? > > Comments welcomed. Historically we officially support the current and previous Mac OS X release (while not doing anything to on-purpose break older releases / being willing to accept patches to make things work on older releases). I think that's a reasonable policy. We have made some effort to support PPC machines for a while longer than that, which was nice, but we probably shouldn't be doing anymore. I don't think we should provide installers/builds for anything other than the supported Mac OS X releases - and I also think we should make sure we're only supporting OS releases that are currently getting security updates from upstream... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mpi
Daniel J. Luke writes: > On Oct 1, 2014, at 1:36 PM, Brandon Allbery wrote: >> >> On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley wrote: >> - Always use clang for C/C++ >> - Drop PPC support >> >> There are a lot of people relying on MacPorts to keep PPCs running. > > they probably shouldn't be. > > I don't think any apple-provided OS that PPC machines can run gets security > patches from Apple anymore... I agree. The development burden of PPC is much, much too high nowadays. Also, having conditional code for which compiler to use based on the OS (and sprinkled all throughout the code) is a maintenance headache. I'll post a new thread about PPC to not derail this one. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RFC: Drop PPC support
As discussed in the MPI thread, PPC is very old and is causing quite the development burden. I would be in favor of discussing how much effort we really want to spend supporting them (similar to supporting libstdc++ on Mavericks). We could tag some known version of the MacPorts svn tree for PPC users and be done with it. This would allow us to concentrate on other issues. We could also talk about how far of an OS back do we really want to support. Tiger and Leopard are decrepit. We don't even have buildbots for PPC nor OSes below Lion. Should we finally drop some of this older stuff? Comments welcomed. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RFC: Renaming GCC ports and variants
Proposal: Since it seems that we are flat-out disallowing gcc being used as a C/C++ compiler, I think it's time to do some clean up of the code: 1) Rename gccXY to gcc-X.Y 2) Rename +gccXY variants to +gfortranXY 3) Start moving away from configure.compiler=macports-gcc* I think it's important for (2) to happen because it make the variant clear as to what it is adding (namely, just a fortran compiler). There are about ~100 ports with gcc variants / configure.compiler being set so, while not being trivial, it's not *that* bad. Due to development burden, I think this kind of decision needs to be across the board (e.g. not be conditional on the OS used). For this proposal, it will hopefully clear up some C++ linking bugs. As a first wave, these would be some ports to tackle: atlas dotwrp julia mpich-* octave openmpi-* petsc py-scipy qrupdate slepc And, of course, update the compilers and mpi portgroups to use the configure.compiler specified. If we can agree on a plan, I can volunteer to do this work and submit my work to be reviewed before committing. Comments welcomed. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mpi
On Oct 1, 2014, at 1:36 PM, Brandon Allbery wrote: > > On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley wrote: > - Always use clang for C/C++ > - Drop PPC support > > There are a lot of people relying on MacPorts to keep PPCs running. they probably shouldn't be. I don't think any apple-provided OS that PPC machines can run gets security patches from Apple anymore... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mpi
On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley wrote: > - Always use clang for C/C++ > - Drop PPC support > There are a lot of people relying on MacPorts to keep PPCs running. In addition, I suspect that 99% of use cases are better handled by: - Always use clang on 10.9 (or maybe 10.8/10.9; in any case it's mandatory on 10.9) - Always use gcc on older platforms -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mpi
vincent writes: >> Yes, atlas has a bunch of compiler variants. I would love for most or all of >> them to go away. But part of atlas needs fortran so it needs to deal with >> that at least. And I believe Vince argued that for atlas and other >> performance-critical scientific software it is beneficial to be able to try >> different compilers to get the absolute best performance. I'm not sure who >> actually has time to do that however. Also, atlas already builds itself >> multiple times with different compiler options to get best performance, >> which is why building atlas takes so long. > > This is mainly historical now. Clang has gone a long way from what it was two > years ago and can now outperform GCC on most kernels. But modern clang > versions are not available on all platforms (10.5 PPC). Besides, fortran is > still required for Atlas as long as you decide to build the BLAS/LAPACK > interface, which almost all other ports depend on. The idea of keeping > multiple gcc variants was to avoid the installation of a fresh copy of GCC > in case the version the user had installed and the one Atlas required weren't > the same, knowing that the version number is nowhere near to be important as > long as the fortran compiler is available (it's just to build the API). The development burden of all these gcc versions is pretty high now. I would suggest a (perhaps controversial) simpler approach: - Always build BLAS/LAPACK for ATLAS (testing for its existence in a dependent port is burdensome) - Always use clang for C/C++ - Drop PPC support > I just wish llvm had a fortran front-end to avoid this mess. And, needless to > say, I'll welcome any suggestion to improve the layout of the port. Ain't that the truth. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mpi
Ryan Schmidt writes: > On Oct 1, 2014, at 12:23 AM, Sean Farley wrote: > >> Ryan Schmidt writes: >> >>> On Sep 30, 2014, at 11:25 PM, Sean Farley wrote: Ryan Schmidt writes: > On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: >> >> Variants create a new node in the dependency DAG. Subports create a new >> node in the dependency DAG. There is no topological difference. The only >> difference is in how they were implemented. > > As far as I understand, variants are not involved in the dependency DAG > in MacPorts at this time. Only ports/subports are. Variants *in MacPorts* are not involved in the DAG *due to implementation*. They do indeed change the graph. >>> >>> I guess I'm not familiar with what graph you're talking about. I'm only >>> concerned with how dependencies work in MacPorts, not some other real or >>> hypothetical package manager. >> >> I'm not talking about a package manager, just the dependency graph. What >> I'm trying to point out is that variants change the graph. For example, >> look at the wonky code of the dependents of cairo, checking for >> cairo+quartz vs. cairo+x11. > > Agreed, quartz and x11 variants are another problem. They are the same problem as boost+mpi. >> It seems that you want to define variants as things that do not change >> the graph. If so, MacPorts would (and should) have to ensure that >> variant blocks don't change the dependencies (but then how to check the >> dependents of a port?). >> >> You would have a simpler definition of a variant (something that enables >> an option but doesn't change the graph) but would end up with more >> (sub)ports. > > A variant that adds a dependency on another port is not a problem. We do this > all the time. But it *does* change the graph when you do that. Which in turn makes it difficult to reproduce stability. > A variant that adds a dependency on a variant of another port is a problem, > in that it's not possible, and the require_active_variants workaround is not > ideal. The solution to this problem is to better handle the dependency graph (which is not easy). >> MPI support is definitely needed. I did not say earlier that would >> work. I said that would only work if you and MacPorts decide to get rid >> of gcc C/C++ compilers (and unify compilers-group with >> configure.compilers). >> >> I am a little worried that you glossed over the amount of work needed to >> make a general solution. There are two big choices: >> >> 1) does the MacPorts community decide to tackle variants, subports, >> graphs, etc.? >> >> 2) does the MacPorts community drop support for gcc as a C/C++ compiler? >> >> (2) is certainly less work but would also lose some advantage over other >> package managers. > > The moment OS X 10.9 came around, we basically lost the ability to > effectively use G++ (and even before then there were some issues). It's out > of our control; we're at the mercy of the C++ library Apple uses, and the > fact that G++ does not use it. That is one path, yes. Much easier than implementing what I'm talking about. What I'm looking for is a definitive "this is when MacPorts decided not to go that route," so I can link to it in the future. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts-MySQL Dictator wanted, prefer benevolent
At 3:07 PM -0500 9/30/14, Ryan Schmidt wrote:
On Sep 30, 2014, at 10:37 AM, Craig Treleaven wrote:
> By way of background, my MythTV ports depend on p5.16-dbd-mysql,
py27-mysql and php-5-mysql. Previously, all of these defaulted to
the now-obsolete mysql5 variant. Now, py-mysql defaults to
mariadb55. p516-dbd-mysql offers a "mariadb" variant; not
"mariadb55". php5-mysql defaults to mysqlind ("MySQL native
driver") and offers a "mariadb" variant; again not "mariadb55".
p5.16-dbd-mysql still defaults to mysql5.
The subtle variance in naming the variants creates confusion. The
range of defaults can lead to bloat and confusion.
Initially, I found there was a ticket related to py-mysql database
variants [1] and I filed additional tickets for php5-mysql [2] and
p5-dbd-mysql [3]. Since then, I thought to search for other ports
that offer variants related to MySQL ('port echo
variant:mysql*')--a total of 89 ports, of which about 20 are
subports.
I've refined my list a little and I've found 83 ports that offer
variants related to MySQL-compatible databases, see attached pdf.
The chart lists all the current variant names; a "1" indicates that a
particular port offers that a variant with that name.
> The tickets have been open for 6 weeks or more with no movement.
I've started to do some analysis on this (with another thread asking
for help) to see if we can standardize on a list of MySQL-related
variant names and maybe even agree on a common default.
>
That's where the dictator comes in. At the moment, I would say
the obvious choices for a default MySQL variant would be mysql55,
mariadb55 or, maybe, mysql56. AFAICT there is no clear-cut,
compelling reason to choose one over the others (technical, legal,
religious, whatever). Other threads have touched on this issue,
recently, with no clear consensus developed. Nonetheless, I think
the MacPorts project would be better served by blessing one that
can hold us for a few years rather than have various ports going in
all different directions.
Is this something that the PortMgr group could take the lead on?
Indeed we have discussed this before, and it was proposed that the
latest stable MariaDB version should be the default variant of ports
that have MySQL support.
I don't think we can or should select a default to last us for
years. We don't want to stagnate like we did with the +mysql5
variant. Rather, we should let the latest stable version be the
default, and update ports as needed.
Currently, the latest stable version of MariaDB is 10.0.
Really? Has MariaDB 10.0 really been sufficiently exercised in the
OS X environment to become the default? Currently, not a single port
that I've identified even offers mariadb-10.0 as a variant. Only 4
ports in my list currently default to mariadb or mariadb55:
PortDefault Variant
akonadi mariadb55
amarok mariadb55
py24-mysql mariadb55
py25-mysql mariadb55
py26-mysql mariadb55
py27-mysql mariadb55
qore-mysql-module mariadb
The question is what to name the variants. This has also been
brought up for discussion before. My most recent thread on the topic
from 2 weeks ago got no replies on the list; perhaps I was too wordy.
My suggestion was that using dots in version numbers, but no
underscores, would be the cleanest and most informative, which would
make the complete list of proposed MySQL variant today: +mariadb5.5,
+mariadb10.0, +mariadb10.1, +mysql5.1, +mysql5.5, +mysql5.6, and
+percona5.6.
Adopting this format means renaming every variant of every affected port.
This may also break the upgrade path for existing installs, no? We
really should keep legacy-named variants for a period of time along
with the new standard which leads to an explosion of variants for
some ports. For example, apr-util currently has mariadb, mysql5,
mysql51, mysql55, mysql56, and percona variants related to db
selection. We'd have to keep those 6 and add at least 6 more (maybe
8 if maridb10.0 and mariadb10.1 are supported).
Perhaps we* could control the explosion of variants by creating a new
Portfile contruct: "legacy-variant". It might act just like the
current variant declaration except that it would be invisible to
'port info' and 'port variants'. Users wouldn't normally see the
legacy-variants thus reducing the temptation to keep using them. If
necessary, perhaps they could be displayed by passing the -v or -d
flags to port.
Craig
* By "we", I mean someone more clever than me!
MacPorts_MySQL_Variants_2014Oct1.xlsx.pdf
Description: Binary data
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: mpi
> Yes, atlas has a bunch of compiler variants. I would love for most or all of > them to go away. But part of atlas needs fortran so it needs to deal with > that at least. And I believe Vince argued that for atlas and other > performance-critical scientific software it is beneficial to be able to try > different compilers to get the absolute best performance. I'm not sure who > actually has time to do that however. Also, atlas already builds itself > multiple times with different compiler options to get best performance, which > is why building atlas takes so long. This is mainly historical now. Clang has gone a long way from what it was two years ago and can now outperform GCC on most kernels. But modern clang versions are not available on all platforms (10.5 PPC). Besides, fortran is still required for Atlas as long as you decide to build the BLAS/LAPACK interface, which almost all other ports depend on. The idea of keeping multiple gcc variants was to avoid the installation of a fresh copy of GCC in case the version the user had installed and the one Atlas required weren't the same, knowing that the version number is nowhere near to be important as long as the fortran compiler is available (it's just to build the API). I just wish llvm had a fortran front-end to avoid this mess. And, needless to say, I'll welcome any suggestion to improve the layout of the port. Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
