I'm a bit disappointed in the polemical nature of some of the comments in this thread. I think we're all better off because of the existence of the FSF and their affiliates, and of a body of useful software under the (L)GPL, even if we prefer another license. No one has forced us to use the work that they've made freely available. With regard to importing clang now, I think that the effort needed for switching to a new compiler will not be greatly diminished by waiting, and we will be better served by learning about possible problems (and attempting to have them fixed upstream) sooner rather than later. Those who are concerned about introducing more variables into debugging will still be free to disregard reports involving clang for now if they choose, and we can emphasize that users should provide information about which compiler is involved in bug reports. Please, will those managing the import follow the recommendation of the tool-chain summit in allowing users to opt out of building and installing clang and any related tools with a knob in src.conf, and add support for ripping it out via the delete-old(-libs) targets and tools/build/mk/OptionalObsoleteFiles.inc, as part of any initial import? Also, others have announced that they are running regression tests on systems built with clang. Would it be possible to set up some regularly scheduled tests to uncover possible problems, if this hasn't been done already? b.Received on Tue Jun 01 2010 - 08:19:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC