On 03/12/07 08:34 -0800, Steve Isaacs wrote:
On Fri, 2007-11-30 at 16:57 -0700, Jordan Crouse wrote:
On 30/11/07 15:29 -0800, Steve Isaacs wrote:
Is it a viable solution to have buildrom build a cross-tool chain? Imho: This would be best in order to have repeatable results. Having config options to control the gcc and binutils versions cross-host build repeatability would be improved.
This is exactly the direction I want to avoid going in. We really don't want to be in the business of building a complete development environment. Its just too much complexity for what we will gain from it.
I understand your sentiment and if I try to look at things from your perspective I can agree. However, I've seen it mentioned that it is the desire of the LinuxBIOS project to get more board manufacturer's involved. For that to happen LinuxBIOS cannot be a moving target.
Look at it from a manufacturer's perspective. The environments in which I have worked require a stringent qualification, test and release process in order to better understand what is being released. Once released, products can be in maintenance for years and service contracts typically determine who gets an update and when. During this time build servers can be replaced and tools typically move through several revisions.
You don't have to worry - as you can infer from the e-mail address, I am keenly aware of the challenges that we have to face for commercial adoption. It is one of my primary goals to ensure that LinuxBIOS becomes and stays a viable option for commercial vendors.
That said, you have to understand that LinuxBIOS and Linux and indeed all of open source will continue to constantly be a moving target. Every day the open source environment presents us with a slightly different view of the world as it twists and turns and evolves.
When I write code, I imagine that every open source project is a train, constantly rolling toward an unknown destination. At every stop, new people are introduced to the project and get on board. They may have heard about the project at a conference, or on a slashdot posting, or just stumbled across it on freshmeat. However they got here, something compelled them to board the train. Whats more, they are going to bring some sort of baggage with them - different distributions (or even operating systems), different languages, and different experiences.
Our job is to make sure that every new person that boards the train is immediately satisfied; because their first perceptions of the code are what determines if they stay or if they immediately get off the train.
This is why we need to make sure that LinuxBIOS works right out of the box with as many different pieces of "baggage" as possible. Buildrom is an excellent tool to help accomplish that, but it can not and should not be essential for all those new passengers to get satisfaction from their first LinuxBIOS experience.
Commercial vendors and manufacturers are no exception - every commercial project has to jump on the train at some point. The code is evaluated and a snapshot of all the current versions, behaviors and bugs in the code is constructed. Once the code has been qualified, it is always wise to freeze the code where it stands, anybody who disagrees obviously hasn't been in the trenches when trying to bring up a new platform. I have numerous projects sitting on my desk right now, not a single one of them that is running kernel version 2.6.24-rcX (heck, none of them are even running 2.6.23).
But this doesn't mean that the train doesn't keep on going without us - the code continues to evolve and prepare itself for the next new passenger.
This is why we (the project) doesn't want to start dictating terms like compiler versions and the like. Once we do that, we start to lose new users and contributors, as the price for admission starts to go up (especially as we start ignoring new features and flaws in newer compilers). Instead, we need to focus our energies on making sure that LinuxBIOS continues to work for every new passenger that gets on our train, and that regardless of what point our commercial vendors and friends decide to freeze, that they'll get the best possible experience from the compilers and applications that they have chosen.
All that said, I think its probably time that we fix this problem once and for all. Ron and Stefan - you are the remaining "experts" on the v2 configuration system - how can we sneak in the $(try-option) calls from buildrom (which were in turned borrowed from the kernel) into LinuxBIOS to put this thing to bed once and for all?
Jordan