Opened 16 years ago
Closed 3 years ago
#19710 closed enhancement (wontfix)
[gcc44] Need finer-grained language selection
| Reported by: | dave@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.7.1 |
| Keywords: | Cc: | krischik@…, kencu (Ken) | |
| Port: | gcc44 |
Description
installing or upgrading gccXY takes forever, because it installs languages like java, fortran, and Ada about which I don't necessarily care. The port should include an option that sets --enable-languages=... on the configure line. For me, that would be --enable-languages=c,c++
Thanks!
Change History (14)
comment:1 Changed 16 years ago by mf2k (Frank Schima)
| Owner: | changed from macports-tickets@… to mww@… |
|---|
comment:2 Changed 16 years ago by blb@…
comment:4 Changed 16 years ago by dave@…
OK, understood. I don't really care how it's handled, but there oughta be a way.
comment:5 Changed 16 years ago by mww@…
Well, as far as I can see, your choices are more or less:
a.) Edit the Portfile (port edit gcc44) prior to each upgrade
b.) Specify the configure.args argument from the command line (port install gcc configure.args="--languages=c,c++ --libdir=/opt/local/lib/gcc44 --.......")
c.) Wait patiently for each build
d.) Hack port(1) to add some feature that solves this problem
comment:6 Changed 16 years ago by dave@…
Thanks; I like option b and didn't know about it, or about option a. Maybe in the meantime the port maintainers could add a note about that to the port's description.
comment:7 Changed 16 years ago by jmroot (Joshua Root)
There shouldn't be a problem adding e.g. a no_fortran variant, should there? Of course selecting it is done at your own risk and you have to promise not to file tickets when dependents that need fortran fail. ;-)
comment:8 Changed 14 years ago by jmroot (Joshua Root)
Probably separate gcjXY and gfortranXY ports would be best.
comment:9 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)
| Owner: | changed from mww@… to macports-tickets@… |
|---|---|
| Status: | new → assigned |
comment:10 Changed 3 years ago by kencu (Ken)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
gcc44 does specify the languages now, and these are the chosen ones:
configure.args --enable-languages=c,c++,objc,obj-c++,java,fortran
comment:11 Changed 3 years ago by jmroot (Joshua Root)
| Cc: | kencu added |
|---|
That's exactly what this ticket was complaining about. So the resolution is really wontfix.
comment:12 Changed 3 years ago by kencu (Ken)
As I read the original ticket, at one time it appears the port set nothing, and it just built default langs.
The ticket author wanted languages specified.
They were. All the same ones that were being built by default :>
comment:13 Changed 3 years ago by kencu (Ken)
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:14 Changed 3 years ago by kencu (Ken)
| Resolution: | → wontfix |
|---|---|
| Status: | reopened → closed |
If the meaning for this ticket was to create a version of gcc44 (etc) that factors the language components into variants, we won't be doing that.
Note that until #126 is fixed, using variants for handling various languages won't be good for dependents. For example, any port which needs gcc44 for gfortran won't get that if the fortran handling is moved into a +fortran variant.