Thanks Wolfgang,
On 03/11/2013 04:15 AM, Wolfgang Denk wrote:
Dear Eric,
In message 513D18F3.2010802@boundarydevices.com you wrote:
I understand the point, but think the pain is manageable and mostly ours.
When I say it doesn't scale, I'm not only thinking about yourown efforts, and your customers.
I also think about things like the increase of build and test time for _everybody_ who performs tests on U-Boot - instead of one board, we now have to build - how many? 6? - configurations. If we allow this now, others will copy this approach (and we cannot really reject it then). I really would like to avoid setting such a precedent here.
Would it help if we restrict the number of boards directly in boards.cfg?
We can easily have local patches for the non-standard memory configurations in our repository, and this will at least allow build tests to include the processor variants.
<snip>
This step has broken things up into parts so that we **can** express multiple memory configurations within a single board directory, and I hope it moves the ball forward a step or two.
It does. But source base is one thing. Havnig to deal with a large number of configurations to build and test is another one, and here you put additional burdon on a large number of prople.
Our hope in getting this main-lined was that other upcoming Solo and Dual-Lite platforms could share some of the bits.
Understood and appreciated. But I also see this ias a strong reason to come up with a clean design, and not create bad examples which others without doubt will interpret as persuasive precedent.
Our hope is that the things we're adding are useful, and not a burden.
We'll be happy to pursue the SPL route, but this won't be something that we can devote cycles to in the next few weeks.
Regards,
Eric