Hi,
I would like to set up a directory with only links to the source files
I use during the building of the kernel. The development ide/editor
will target this directory instead of main source tree. The benefit of this
is that I don't need to bother about files that are not included
by the configuration.
Can I do this by something like....
make linked_directory
If not, what part of make is a good starting point?
/Pelle
On Wed, Jan 03, 2007 at 04:24:11PM +0100, Pelle Svensson wrote:
> Hi,
>
> I would like to set up a directory with only links to the source files
> I use during the building of the kernel. The development ide/editor
> will target this directory instead of main source tree. The benefit of this
> is that I don't need to bother about files that are not included
> by the configuration.
Anohter approach would be to use a separate output directory.
In this way you have all generated files in a separate place which
should solve your needs.
To use it do like this:
make mrproper <= To get a clean starting point
mkdir ../o
make O=../o defconfig <= or some other config target
cd ../o
make
Se also README.
Sam
Hi Sam,
You misunderstand me I think, I already using a separate output directory.
What I like to do is a separate 'source tree' with only valid files
for my configuration. In that way, when I use grep for instance,
I would only hit valid files and not 50 other files which are
not in the current build configuration.
On 1/3/07, Sam Ravnborg <[email protected]> wrote:
> On Wed, Jan 03, 2007 at 04:24:11PM +0100, Pelle Svensson wrote:
> > Hi,
> >
> > I would like to set up a directory with only links to the source files
> > I use during the building of the kernel. The development ide/editor
> > will target this directory instead of main source tree. The benefit of this
> > is that I don't need to bother about files that are not included
> > by the configuration.
>
> Anohter approach would be to use a separate output directory.
> In this way you have all generated files in a separate place which
> should solve your needs.
>
> To use it do like this:
>
> make mrproper <= To get a clean starting point
> mkdir ../o
> make O=../o defconfig <= or some other config target
> cd ../o
> make
>
> Se also README.
>
> Sam
>
On Wed, 03 Jan 2007 22:14:43 +0100, Pelle Svensson said:
> Hi Sam,
>
> You misunderstand me I think, I already using a separate output directory.
> What I like to do is a separate 'source tree' with only valid files
> for my configuration. In that way, when I use grep for instance,
> I would only hit valid files and not 50 other files which are
> not in the current build configuration.
This is covered in the Kernel FAQ:
http://www.tux.org/lkml/#s7-7
"The kernel source is HUUUUGE and takes too long to download. Couldn't it be
split in various tarballs?
The kernel (as of 2.1.110) has about 1.5 million lines of code in *.c, *.h and
*.S files. Of those, about 253 k lines (17%) are in the architecture-specific
subdirectories, and about 815 k lines (54%) are in platform-independent
drivers. If, like most people, you are only interested in i386, you could save
about 230 k lines by removing the other architecture-specific trees. That is a
15% saving, which is not that much, really. The "core" kernel and filesystems
take up about 433 k lines, or around 29%.
If you want to start pruning drivers away, the problem becomes much harder,
since most of that code is architecture independent. Or at least, is supposed
to be/will be. There is some driver code which probably should be moved to an
i386-specific subdirectory, and perhaps over time it will be (it will take a
lot of work!), but you need to be careful. PCI cards for example should be
architecture independent. Throwing out the non i386-specific drivers will save
around 97 k lines, a saving of about 6%.
But the most important argument for/against splitting the kernel sources is not
about how much space/download time you could save. It's about the work involved
for Linus or whoever will be putting together the kernel releases. Building
tarballs (compressed tarfiles) of the whole kernel already represents a
considerable amount of work; splitting it into various architecture-dependent
tarballs would dramatically increase this effort and would probably pose
serious maintainability problems too.
If you are really desperate for a reduced kernel, set up some automated
procedure yourself, which takes the patches which are made available, applies
them to a base tree and then tars up the tree into multiple components. Once
you've done all this, make it available to the world as a public service. There
will be others who will appreciate your efforts."
In other words, it won't help as much as you think. And note that you'd
*really* need to make it config-specific - the instant you change *any*
option in that .config, you're likely now including some newoption.c file
that will fail your kernel build... Whoops.
On Wed, Jan 03, 2007 at 10:14:43PM +0100, Pelle Svensson wrote:
> Hi Sam,
>
> You misunderstand me I think, I already using a separate output directory.
> What I like to do is a separate 'source tree' with only valid files
> for my configuration. In that way, when I use grep for instance,
> I would only hit valid files and not 50 other files which are
> not in the current build configuration.
I see.
There is nothing in kbuild that will help you to achieve this.
If you build the kernel and parse all .*.cmd files then
you can build a complete list of files used and create your
symlinked tree.
But then you need a fully build kernel to do so.
I see no easy way to get the info without building the kernel
and if we do this only as a preprocessing step then we will
most likely not integrate it in kbuild since the user base will
be small. But if you hack up something lets take a look at it.
Sam
On 1/3/07, Sam Ravnborg <[email protected]> wrote:
> On Wed, Jan 03, 2007 at 10:14:43PM +0100, Pelle Svensson wrote:
> > Hi Sam,
> >
> > You misunderstand me I think, I already using a separate output directory.
> > What I like to do is a separate 'source tree' with only valid files
> > for my configuration. In that way, when I use grep for instance,
> > I would only hit valid files and not 50 other files which are
> > not in the current build configuration.
>
> I see.
> There is nothing in kbuild that will help you to achieve this.
> If you build the kernel and parse all .*.cmd files then
> you can build a complete list of files used and create your
> symlinked tree.
> But then you need a fully build kernel to do so.
>
> I see no easy way to get the info without building the kernel
> and if we do this only as a preprocessing step then we will
> most likely not integrate it in kbuild since the user base will
> be small. But if you hack up something lets take a look at it.
>
> Sam
>
Hi Sam,
Ok, at least I know I'm not doing double work.
/Thanks
Pelle Svensson wrote:
> Hi Sam,
>
> You misunderstand me I think, I already using a separate output directory.
> What I like to do is a separate 'source tree' with only valid files
> for my configuration. In that way, when I use grep for instance,
> I would only hit valid files and not 50 other files which are
> not in the current build configuration.
So take a look at those generated files - there are .dep files in there,
which lists dependencies of every file which has been compiled for your
configuration. Take them, build a list of filenames, and (sym)link them
into separate dir. Some small awk/sed/grep/sort/uniq/xargs/ln magic and
you're done... ;)
/mjt