how to configure/build a kernel in a separate directory?

how to configure/build a kernel in a separate directory?

[Robert P. J. Day]

  (i originally posted this to the "make" mailing list, but i figured 
someone here *must* have done this before.)

  is there an easy way to configure/build one or both of a 2.4 and 2.6 
kernel in a totally separate directory from the source directory itself?

  i'd like to have a totally pristine ("make mrproper"ed) source tree,
write-protected, readable by all, so that several developers can 
independently configure and build their own kernels without stepping on 
each other.  currently, they all check out their own copy of the source 
via CVS, which starts to take up a lot of space.

  obviously, it would be great if they could all set up some kind of build 
structure where they could do their own configuration and build in their 
personal work directories, so that *all* generated results (header files,
object files, etc.) are placed in their work directory -- nothing should
be generated in the kernel source tree itself.

  i'm suspecting that, if there are solutions, they will be different from 
2.4 to 2.6, so i'll take whatever solutions i can get.  others have 
suggested using gnu make in combination with "VPATH", but i'm not sure 
that's going to work, as VPATH deals strictly with pre-requisites in other 
directories, not executable programs like scripts.

rday

p.s.  it gets more exciting since developers might want to create a 
downloadable image combination of a kernel and root filesystem, so they
might want to have independent copies of 
arch/<arch>/boot/images/ramdisk.image.gz, but i'll fight with that when
the time comes.

Re: how to configure/build a kernel in a separate directory?

[Richard B. Johnson]

On Mon, 7 Jun 2004, Robert P. J. Day wrote:

>
>   (i originally posted this to the "make" mailing list, but i figured
> someone here *must* have done this before.)
>
>   is there an easy way to configure/build one or both of a 2.4 and 2.6
> kernel in a totally separate directory from the source directory itself?
>
>   i'd like to have a totally pristine ("make mrproper"ed) source tree,
> write-protected, readable by all, so that several developers can
> independently configure and build their own kernels without stepping on
> each other.  currently, they all check out their own copy of the source
> via CVS, which starts to take up a lot of space.
>
>   obviously, it would be great if they could all set up some kind of build
> structure where they could do their own configuration and build in their
> personal work directories, so that *all* generated results (header files,
> object files, etc.) are placed in their work directory -- nothing should
> be generated in the kernel source tree itself.
>
>   i'm suspecting that, if there are solutions, they will be different from
> 2.4 to 2.6, so i'll take whatever solutions i can get.  others have
> suggested using gnu make in combination with "VPATH", but i'm not sure
> that's going to work, as VPATH deals strictly with pre-requisites in other
> directories, not executable programs like scripts.
>
> rday


I would make a script that creates a symbolic-link of all the
source-files and headers. To get it right, put the source on
a r/o file-system as a start. It's a lot of work.

`find . -name "*.[chS]"` should get all the sources, but there
are some scripts you will have to hunt for.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: how to configure/build a kernel in a separate directory?

[Sean Neakums]

"Robert P. J. Day" <rpjday@mindspring.com> writes:

>   is there an easy way to configure/build one or both of a 2.4 and 2.6 
> kernel in a totally separate directory from the source directory itself?
>
>   i'd like to have a totally pristine ("make mrproper"ed) source tree,
> write-protected, readable by all, so that several developers can 
> independently configure and build their own kernels without stepping on 
> each other.

This isn't really what you want, but you can use 'cp -rl' to build a
hard-linked tree from the pristine read-only tree and build there.
This will at least address the space issue.

Re: how to configure/build a kernel in a separate directory?

[Sam Ravnborg]

On Mon, Jun 07, 2004 at 05:00:26PM -0400, Robert P. J. Day wrote:
> 
>   (i originally posted this to the "make" mailing list, but i figured 
> someone here *must* have done this before.)
> 
>   is there an easy way to configure/build one or both of a 2.4 and 2.6 
> kernel in a totally separate directory from the source directory itself?

For 2.4 you are out of luck. At least I do not know of any patch that
should allow you to do that with current 2.4 kernel.

For 2.6 you just use (executed in root of kernel src):

make O=dir/to/put/output target

Se make help + README for a bit more info.

	Sam

Re: how to configure/build a kernel in a separate directory?

[Bernd Petrovitsch]

On Mon, 2004-06-07 at 23:31, Richard B. Johnson wrote:
> On Mon, 7 Jun 2004, Robert P. J. Day wrote:
[...]
> >   (i originally posted this to the "make" mailing list, but i figured
> > someone here *must* have done this before.)

Not only here. And yes.

> >   is there an easy way to configure/build one or both of a 2.4 and 2.6
> > kernel in a totally separate directory from the source directory itself?
> >
> >   i'd like to have a totally pristine ("make mrproper"ed) source tree,
> > write-protected, readable by all, so that several developers can
> > independently configure and build their own kernels without stepping on
> > each other.  currently, they all check out their own copy of the source
> > via CVS, which starts to take up a lot of space.
> >
> >   obviously, it would be great if they could all set up some kind of build
> > structure where they could do their own configuration and build in their
> > personal work directories, so that *all* generated results (header files,
> > object files, etc.) are placed in their work directory -- nothing should
> > be generated in the kernel source tree itself.
> >
> >   i'm suspecting that, if there are solutions, they will be different from
> > 2.4 to 2.6, so i'll take whatever solutions i can get.  others have
> > suggested using gnu make in combination with "VPATH", but i'm not sure
> > that's going to work, as VPATH deals strictly with pre-requisites in other
> > directories, not executable programs like scripts.

VPATH works for make, but not for other scripts and tools.

> I would make a script that creates a symbolic-link of all the
> source-files and headers. To get it right, put the source on
> a r/o file-system as a start. It's a lot of work.

No, lndir exists (somewhere in X11 or XFree86 IIRC).
Just make a sym-linked copy of the (read-only) pristine source
directory.
Voila. And quite easy.

> `find . -name "*.[chS]"` should get all the sources, but there
> are some scripts you will have to hunt for.

No, just take all files which are there. It is simple and works.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: how to configure/build a kernel in a separate directory?

[Robert P. J. Day]

On Mon, 7 Jun 2004, Sean Neakums wrote:

> "Robert P. J. Day" <rpjday@mindspring.com> writes:
> 
> >   is there an easy way to configure/build one or both of a 2.4 and 2.6 
> > kernel in a totally separate directory from the source directory itself?
> >
> >   i'd like to have a totally pristine ("make mrproper"ed) source tree,
> > write-protected, readable by all, so that several developers can 
> > independently configure and build their own kernels without stepping on 
> > each other.
> 
> This isn't really what you want, but you can use 'cp -rl' to build a
> hard-linked tree from the pristine read-only tree and build there.
> This will at least address the space issue.

i was reminded of the easy solution with the 2.6 kernel, so that's a 
relief.  sadly, it's the 2.4 case that's more important to me at the 
moment, and it looks like it's major symlink time.  oh well ... more 
incentive to move on up to 2.6.

thanks.

rday

Re: how to configure/build a kernel in a separate directory?

[Michelle Konzack]

[-- Attachment #1: Type: text/plain, Size: 4466 bytes --]

Am 2004-06-07 17:00:26, schrieb Robert P. J. Day:

>  is there an easy way to configure/build one or both of a 2.4 and 2.6 
>kernel in a totally separate directory from the source directory itself?

YES 

>  i'd like to have a totally pristine ("make mrproper"ed) source tree,
>write-protected, readable by all, so that several developers can 
>independently configure and build their own kernels without stepping on 
>each other.  currently, they all check out their own copy of the source 
>via CVS, which starts to take up a lot of space.

Right

>  obviously, it would be great if they could all set up some kind of build 
>structure where they could do their own configuration and build in their 
>personal work directories, so that *all* generated results (header files,
>object files, etc.) are placed in their work directory -- nothing should
>be generated in the kernel source tree itself.
>
>  i'm suspecting that, if there are solutions, they will be different from 
>2.4 to 2.6, so i'll take whatever solutions i can get.  others have 
>suggested using gnu make in combination with "VPATH", but i'm not sure 
>that's going to work, as VPATH deals strictly with pre-requisites in other 
>directories, not executable programs like scripts.

/usr/X11R6/bin/lndir

If you use Debian GNU/Linux, the file is in the Package: xutils

  ____ (stdin) _________________________________________________________
 /
|  LNDIR(1)                                                 LNDIR(1)
|  
|  
|  
|  N\bNA\bAM\bME\bE
|         lndir  -  create  a  shadow directory of symbolic links to
|         another directory tree
|  
|  S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
|         l\bln\bnd\bdi\bir\br [ -\b-s\bsi\bil\ble\ben\bnt\bt ] [ -\b-i\big\bgn\bno\bor\bre\bel\bli\bin\bnk\bks\bs ] _\bf_\br_\bo_\bm_\bd_\bi_\br [ _\bt_\bo_\bd_\bi_\br ]
|  
|  D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
|         The _\bl_\bn_\bd_\bi_\br program makes a shadow copy _\bt_\bo_\bd_\bi_\br of a directory
|         tree _\bf_\br_\bo_\bm_\bd_\bi_\br_\b, except that the shadow is not populated with
|         real files but instead with symbolic links pointing at the
|         real files in the _\bf_\br_\bo_\bm_\bd_\bi_\br directory tree.  This is usually
|         useful for maintaining source code for  different  machine
|         architectures.   You  create a shadow directory containing
|         links to the real source,  which  you  will  have  usually
|         mounted  from  a  remote  machine.   You  can build in the
|         shadow tree, and the object files will be  in  the  shadow
|         directory,  while the source files in the shadow directory
|         are just symlinks to the real files.
|  
|         This scheme has the  advantage  that  if  you  update  the
|         source,  you  need  not  propagate the change to the other
|         architectures by hand, since  all  source  in  all  shadow
|         directories are symlinks to the real thing: just cd to the
|         shadow directory and recompile away.
|  
|         The _\bt_\bo_\bd_\bi_\br argument is optional and defaults to the current
|         directory.   The  _\bf_\br_\bo_\bm_\bd_\bi_\br  argument may be relative (e.g.,
|         ../src) and is relative to _\bt_\bo_\bd_\bi_\br (not the  current  direc­
|         tory).
|  
|         Note  that  RCS, SCCS, CVS and CVS.adm directories are not
|         shadowed.
|  
|         If you add files, simply run _\bl_\bn_\bd_\bi_\br again.  New files  will
|         be  silently  added.   Old files will be checked that they
|         have the correct link.
|  
|         Deleting files is a more  painful  problem;  the  symlinks
|         will just point into never never land.
|  
|         If  a  file in _\bf_\br_\bo_\bm_\bd_\bi_\br is a symbolic link, _\bl_\bn_\bd_\bi_\br will make
|         the same link in _\bt_\bo_\bd_\bi_\br rather than making a link  back  to
|         the  (symbolic  link)  entry in _\bf_\br_\bo_\bm_\bd_\bi_\br_\b.  The -\b-i\big\bgn\bno\bor\bre\bel\bli\bin\bnk\bks\bs
|         flag changes this behavior.
|  

<snip>

|  X Version 11               Release 6.5                   LNDIR(1)
 \______________________________________________________________________


>rday

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]