From: Jack H. <ho...@br...> - 2008-08-11 20:33:16
|
Benjamin, I'm fine with the fink.conf approach to opt into gcc-4.2 as long as it gets added in the near term to unstable. Jack On Mon, Aug 11, 2008 at 03:53:47PM -0400, Benjamin Reed wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (CC'ing fink-core) > > Jack Howarth wrote: > | Benjamin, > | If it is a 10.5-gcc-4.2 branch, I would assume by default it > | would be an opt in. Besides, I would surprised if Apple doesn't switch > | the default compiler to gcc-4.2 for Snow Leopard so we will likely > | want to do that for 10.6 anyway. Why can't we just create a 10.5-gcc-4.2 > | branch, dump unstable over into it and set fink to build with gcc-4.2. > | Then fink developers could play with that branch at their leisure. > > My point is, if we add support for users to opt-in to GCC 4.2 through > fink.conf, we don't need a branch! > > People can continue to use fink just as it is now. People who want the > performance update can move to 4.2, and can submit patches with fixes > (or bug reports) for packages as-needed. > > I think it is a bad idea to have another all-or-nothing branch, it was a > pain for 3.3->4.0, it was a pain for pangocairo; it's a lot of work, and > the only reason to do it was because it was a forced catastrophic change > and it was something we couldn't do without a lot of pain for the user > in the meantime. Making a branch should be a last resort, not the default. > > | Also, I don't think performance improvements is a small deal overall. > > They are not a small deal for *you*. But that guy with an 800Mhz G4 who > only uses fink for 2 programs that he runs once a month is not > interested in spending 3 days downloading Xcode 3.1.1 and/or compiling a > new gcc just to get a performance update he doesn't need or want. Fink > has a very *very* wide range of use-cases, and performance is only one > of them. > > | My instinct is that most everything will build fine that uses recent > | upstream sources. Using a gcc-4.3 would be more problematic. If anything > | I suspect the biggest effort will be removing any patches added to > packages > | to build on the older gcc 4.0.1. > > Again, I'm not saying not to work on making things work with 4.2. > Performance is good. I'm all for it. But, Fink's strength has been in > making transitions easy for users. Rebuilding everything all at once > because we said so is not an easy transition for the users. > > It shouldn't take much perl code to make Fink allow gcc 4.2 since we > already wrap GCC for the GCC: field. That should be step 1. > > ~From there, people can opt-in to using 4.2 instead of 4.0, and we can > fix packages. Those packages which need to depend on 4.2 can depend on > whatever mechanism we use to note that it's available (system-gcc-blah > or whatever). > > | ps I would assume we would use -2XXX subversions for packages in > | 10.5-gcc4.2 that require specific patches or only build against > | gcc 4.2 (like ppl). Otherwise most everything else will likely > | build unchanged from 10.4/10.5. > > It should be possible to make patches that continue to work with older > gccs, in which case it should not be necessary to do that. 4.2 is > ABI-compatible with 4.0.1 binaries, right? > > It's no different than building against OSX 10.5.4. It's assumed that > if you built fink stuff on 10.5.4, your binaries probably won't work on > 10.5.0. Going forward in a binary-compatible way doesn't require > revision bumps. Only changing ABI or library compatibility or some such > does. > > In the end, Fink's most precious resource is time. A lot of us don't > have time to work on all-or-nothing big projects; look how long it to > for pangocairo to get finished, even when a not insignificant number of > people were spending many hours on it. It is not a good idea to do a > big branch and dump it on everyone at once unless there is no > alternative, and in this case, I think there is definitely an alternative. > > Those who are performance-minded can always opt-in, but it's not worth > forcing everyone to do it, when it *also* means forcing maintainers into > spending a bunch of time they already don't have on the transition, and > forcing users to spend significant time on something they may or may not > want. > > - -- > Benjamin Reed a.k.a. Ranger Rick > Fink, KDE, and Mac OS X development > > Blog: http://www.raccoonfink.com/ > Music: http://music.raccoonfink.com/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIoJjLUu+jZtP2Zf4RArNJAJ0b1CPtj7oivitFiQEdi7j0OpSmogCgoES/ > WFQfjAtDRSDbr5Ku99y/sqc= > =gG6G > -----END PGP SIGNATURE----- |