| 1 |
On Sun, Jan 12, 2014 at 01:53:47AM -0600, Ryan Hill wrote: |
| 2 |
> While I'm adding USE defaults to toolchain.eclass and moving them out of the |
| 3 |
> profiles, I thought now would be a good time to review a couple default flag |
| 4 |
> settings. |
| 5 |
> |
| 6 |
> mudflap: |
| 7 |
> This is currently enabled by default but I'd like to disable it. It controls |
| 8 |
> libmudflap and the -fmudflap flag. I think the only reason this flag exists is |
| 9 |
> so we can disable it in crossdev. It's not required by anything in the tree, |
| 10 |
> the code is bitrotten and has been removed for GCC 4.9. If you know how to use |
| 11 |
> -fmudflap, you know how to set a USE flag. |
| 12 |
|
| 13 |
No-brainer, yeah. |
| 14 |
|
| 15 |
> fortran: |
| 16 |
> Do we want to keep enabling fortran by default? The majority of users will |
| 17 |
> never get the urge to install a fortran package, and the fortran eclass handles |
| 18 |
> those that do. I think it should be treated as all the other optional |
| 19 |
> languages and disabled by default, but I'd like to know if there are other |
| 20 |
> opinions. |
| 21 |
|
| 22 |
Yes, keep it. It's used in the oddest places, and still beats C for numeric |
| 23 |
processing. It's not like gcj which is a pig to build, and to which there are |
| 24 |
many alternative implementations that may well be preferred, given the state |
| 25 |
of Java. IMO it's important to have, and there's no real benefit to keeping |
| 26 |
it off, for the general user. Anyone who wants to keep it slim already has it |
| 27 |
disabled in package.use. |
| 28 |
|
| 29 |
-- |
| 30 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives