[uClibc] Updating uClibc/extra/config to match Linux 2.6.11

[Peter Kjellerstedt]

*ping*

//Peter

> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Peter Kjellerstedt
> Sent: Tuesday, March 22, 2005 19:07
> To: Erik Andersen
> Cc: uclibc at uclibc.org
> Subject: [uClibc] Updating uClibc/extra/config to match Linux 2.6.11
> 
> I am in the process of updating uClibc/extra/config. It is 
> currently based on scripts/kconfig and scripts/lxdialog from 
> Linux 2.6.7. I intend to update it to match Linux 2.6.11.
> 
> First, uClibc/extra/config currently contains a merge of the 
> two directories from the Linux sources. Due to the fact that
> there is now a utils.c in both of those directories, I
> intend to separate them again, and move the files from
> lxdialog into uClibc/extra/config/lxdialog. This should not
> be much of a problem.
> 
> Second, I would like to import scripts/kconfig and 
> scripts/lxdialog into the uClibc repository somewhere to 
> make it easier to perform similar updates in the future. 
> Unfortunately (for me), there is currently no standard for 
> how to handle imports like this in the uClibc repository.
> 
> Here are a couple of possibilities (/vendor would be a new
> top directory along /trunk, /tags and /branches):
> 
> /vendor/kconfig/current
> /vendor/kconfig/linux-2.6.11 (copy of the previous, aka tag)
> /vendor/lxdialog/current
> /vendor/lxdialog/linux-2.6.11 (copy of the previous, aka tag)
> 
> /vendor/linux/kconfig
> /vendor/linux/lxdialog
> /vendor/linux-2.6.11/kconfig
> /vendor/linux-2.6.11/lxdialog
> 
> /vendor/linux/current/kconfig
> /vendor/linux/current/lxdialog
> /vendor/linux/2.6.11/kconfig
> /vendor/linux/2.6.11/lxdialog
> 
> /vendor/linux/scripts/kconfig
> /vendor/linux/scripts/lxdialog
> /vendor/linux-2.6.11/scripts/kconfig
> /vendor/linux-2.6.11/scripts/lxdialog
> 
> The first version above is similar to the one suggested in 
> http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-7-sect-4.1
> The second one more resembles the way /tags and /branches are 
> currently laid out. The third version is basically the same
> as the second, but the vendor and the version have been
> separated into different directories. The fourth version is
> the same as the second but retaining the directory structure
> of the original source. 
> 
> I do not know which version is preferred, but I personally lean 
> towards the third or fourth (or the combination of them).
> 
> //Peter