(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.
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
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.
"Robert P. J. Day" <[email protected]> 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.
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
On Mon, 7 Jun 2004, Sean Neakums wrote:
> "Robert P. J. Day" <[email protected]> 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
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)
|
|
|
| NNAAMMEE
| lndir - create a shadow directory of symbolic links to
| another directory tree
|
| SSYYNNOOPPSSIISS
| llnnddiirr [ --ssiilleenntt ] [ --iiggnnoorreelliinnkkss ] _f_r_o_m_d_i_r [ _t_o_d_i_r ]
|
| DDEESSCCRRIIPPTTIIOONN
| The _l_n_d_i_r program makes a shadow copy _t_o_d_i_r of a directory
| tree _f_r_o_m_d_i_r_, except that the shadow is not populated with
| real files but instead with symbolic links pointing at the
| real files in the _f_r_o_m_d_i_r 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 _t_o_d_i_r argument is optional and defaults to the current
| directory. The _f_r_o_m_d_i_r argument may be relative (e.g.,
| ../src) and is relative to _t_o_d_i_r (not the current direc?
| tory).
|
| Note that RCS, SCCS, CVS and CVS.adm directories are not
| shadowed.
|
| If you add files, simply run _l_n_d_i_r 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 _f_r_o_m_d_i_r is a symbolic link, _l_n_d_i_r will make
| the same link in _t_o_d_i_r rather than making a link back to
| the (symbolic link) entry in _f_r_o_m_d_i_r_. The --iiggnnoorreelliinnkkss
| 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)