#28288: RFE · SuiteSparse should be bumped to 3.6.0 and use macports gcc --------------------------------+------------------------------------------- Reporter: vince@… | Owner: stechert@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: upgrade | Port: SuiteSparse --------------------------------+------------------------------------------- Comment(by vince@…): Additionally, Accelerate framework dependencies should be replaced by our atlas build. -- Ticket URL: <https://trac.macports.org/ticket/28288#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#28288: RFE · SuiteSparse should be bumped to 3.6.0 and use macports gcc --------------------------------+------------------------------------------- Reporter: vince@… | Owner: stechert@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: SuiteSparse --------------------------------+------------------------------------------- Changes (by ryandesign@…): * keywords: upgrade => Comment: SuiteSparse was updated to 3.7.0 in r88507. The remaining statement in the summary is that the port should use MacPorts gcc. Why should it do this? I don't understand the statement "it does not support building with any other compiler than the Apple gcc 4.2, which is not nice." As far as I know, it supports building with the default compiler, whatever that is for your version of Xcode (gcc-4.0, gcc-4.2, llvm-gcc-4.2, clang), just like most other ports. This is completely nice and normal. It is not common to offer variants to build with MacPorts gcc compilers, unless the default compilers are not sufficient, and in this case they appear to be sufficient. If you want us to evaluate your proposed changes, supply a unified diff of the Portfile, not an entire new Portfile. Why do we need such a complicated wrapper script to build universal? The port (until it was updated to 3.7.0 -- see #32754) built universal just fine without such a wrapper. In addition, we already have the muniversal portgroup and the "merge" procedure available as alternative universal implementations; I would hope we don't need yet another. -- Ticket URL: <https://trac.macports.org/ticket/28288#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS