Re: standardizing on a language
On Mon, Sep 26, 2005 at 07:35:48AM +0200, Sven Luther wrote:
> On Mon, Sep 26, 2005 at 12:57:32PM +0900, Horms wrote:
> > On Thu, Sep 22, 2005 at 09:53:14PM +0200, Sven Luther wrote:
> > > On Thu, Sep 22, 2005 at 03:36:01PM -0400, Andres Salomon wrote:
> > > > Ok, looks like people seem to want python more; I'll start rewriting
> > > > my tools to be in python, and working on the common lib stuff.
> > >
> > > Make sure to write a one paragraph in the "split-config howto for the dumbs"
> > > kind though.
> >
> > split-config has had useful help output every time I have tried to use it.
>
> $ ../../trunk/scripts/split-config
> Usage: ../../trunk/scripts/split-config [options] <config dir> <flavour>
> -a, --arch <arch> select architecture [powerpc]
> -s, --subarch <arch> select sub-architecture []
> -c, --configtype <type> select config type [menuconfig]
> -h, --help display this help screen
>
> Well, the main remaining question is :
>
> 1) where do we invoke it.
In the root of a kernel tree, with debian patches applied.
Preferably with the debian/ directory in place.
In short, in the root directory of something that looks like an
unpacked pacakge.
Speaking of which, can we have the patch and unpatch targets
back in debian/rules. And perhaps add some split-config targets?
> 2) when to use -a and -s.
Use -a if you want to edit the config for an architecture
other than the one you are using. For instance, on powerpc
you could use this option to edit and i386 config, and vice-versa.
> 3) what is the config_dir and why do we need it.
That is the directory tree where the configs are stored.
If you are in the root of a tree with a complete debian/
directory then this will be debian/arch/
That could probably be made the default.
> 4) if i want to change an option accross all flavours, how do i do it.
Make the change locally, then it will ask you how broadly
you want the the change applied: global, architecture, sub-architecture
or flavour.
> I mean, due to 1), i was never able to go beyond this help output message, and
> i tried it in all imaginable places.
>
> I guess there is not much needed to make it happen, but there is this barrier
> to entry which seems difficulty crossable without a lot of experimentation.
I guess it depends how you guess. I found it very easy,
but there is always room for more documentation. How about
just adding the above to to code in svn, thats what we are all
running anyway.
> The best thing to solve this would be one simple example of how it is used,
> would take all of 10 lines or so, maybe appended to the below output or in a
> -e, --example option ? Or a -e, --extendedhelp one ?
No objections here.
Note: As discussed, there is a but whereby if you run on
an architecture such as powerpc or x86_64 where the debian
architecture name is different from the kernel architecture name,
the script will fail. A simple hack is to just hardcode
your architecture rather than using ARCH in the line that
invokes make.
I thought of puting a simple lookup table in the code.
But there hae been a few suggestions on IRC that the information
is already in the tree, can we make this happen, or are
we just going to can this and use python?
--
Horms
Reply to: