"C. Bergstr?m" writes: > James Carlson wrote: > > For some, that's true; for others, not so true. I don't disagree with > > what you're doing, but it's worth pointing out that others are headed > > in other directions, and that licensing issues are not necessarily > > absolutes. > > > If there's no promise from [insert-name-of-company] to open source it > and the source isn't available *today*.. it doesn't exist.. I realize > that's a hard line and I may/will duplicate work, but c'est la vie.. (A > good example is the sun cc compilers (w/o the optimization libs) I hear > rumors it can be done and it's planned.. it would be *really* great, but > hasn't happened)
As I said, I don't disagree with what you're doing. I understand what you're saying, but that's not the only possible political position on this issue. For instance, the line the OpenSolaris distribution folks drew was between binaries that are freely redistributable (regardless of source restrictions) and those that are not. It's also a valid choice, but quite different in implications. > > I'm not sure that's compatible at the binary level like that. > > > > Are you also using only open-source C/C++ compilers? > > > > > For my first pass I'm trying to reduce the number of variables to my > changes or minimize at least. (since I'm changing other things besides > removing the closed bins..) The reason I ask is that I don't see a great deal of philosophical difference between relying on an OCO (object code only) tool chain and relying on a few tool-chain-related OCO components, such as libCrun. Both are "impure" from the open-source-only standpoint I think you're trying to take. > 2nd pass I'm aiming at fully open toolchain as well.. With open64 I'll > have to make other changes to how ON is compiled. stab debugging format > is explicitly being used which isn't supported by open64.. (seemingly > small change, but I've tested and had unexpected issues) Do you mean the www.open64.net "open research compiler?" If so, then I don't doubt that there'll be issues. I don't know what the other consolidations are doing, but for ON, we intentionally committed to supporting only two C/C++ compilers: Sun's WorkShop and gcc. Even at that, we support only very specific versions of each, and changing versions is a big deal, requiring extensive testing, and often some code rework. Supporting a brand new compiler in the chain would be quite hard. Real support here means not just getting it to compile once. Nor is it sufficient to integrate fixes and hope for the best in the future. To get real support, all of the contributors need to build and test with all of the supported compilers (so that they know they're not contributing things that will break others), and the gatekeepers as well have to build regularly with all of the supported build environments. It's a change of process as well as a change of code. It sounds like an interesting project, but unless there's some buy-in from the others who'd be affected, I think you might be talking about a fork of the code. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
