Opened 14 years ago
Closed 9 years ago
#28288 closed enhancement (fixed)
RFE · SuiteSparse should be bumped to 3.6.0 and use macports gcc
| Reported by: | Veence (Vincent) | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.9.2 |
| Keywords: | Cc: | seanfarley (Sean Farley) | |
| Port: | SuiteSparse |
Description
The SuiteSparse port is outdated. Albeit it has been made universal a few days ago, which is nice, it does not support building with any other compiler than the Apple gcc 4.2, which is not nice.
Attachments (3)
Change History (8)
comment:1 Changed 14 years ago by Veence (Vincent)
comment:2 Changed 14 years ago by Veence (Vincent)
Here is an experimental Portfile that enables compilation with gcc45 in two-way universal code. Compiling SuiteSparse with gcc45 seems to be required to integrate it in numpy/scipy.
Changed 14 years ago by Veence (Vincent)
| Attachment: | c-wrapper-template added |
|---|
A c/c++ "wrapper" to allows two-way universal builds
Changed 14 years ago by Veence (Vincent)
| Attachment: | patch_UFconfig_makefile.diff added |
|---|
A further needed patch for universal build
comment:3 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
| Keywords: | upgrade removed |
|---|
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.
comment:4 Changed 13 years ago by jmroot (Joshua Root)
| Cc: | stechert@… removed |
|---|---|
| Owner: | changed from stechert@… to macports-tickets@… |
-> nomaintainer
comment:5 Changed 9 years ago by jmroot (Joshua Root)
| Cc: | sean@… added |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Long since updated, and compilers portgroup was added in r116387.
Additionally, Accelerate framework dependencies should be replaced by our atlas build.