On Tue, 19 Nov 2002, Daniel Jacobowitz wrote:
> On Tue, Nov 19, 2002 at 03:46:28PM -0500, Richard B. Johnson wrote:
> > On Tue, 19 Nov 2002, Sam Ravnborg wrote:
> >
> > > On Tue, Nov 19, 2002 at 03:22:45PM -0500, Richard B. Johnson wrote:
> > > > I have a question; "What problem is this supposed to solve?"
> > >
> > > Two problems (at least):
> > >
> > > 1) You want to compile your kernel based on two different configurations,
> > > but sharing the same src. No need to have a duplicate of all src.
> > > - There are other ways to do this using symlinks
> > >
> > > 2) You have the src located on a read-only filesystem.
> > > I have been told this is the case for some SCM systems.
> > >
> > > People has requested this feature at several occasions, and here
> > > it is based on the current build system.
> > > It's not ready for inclusion (obviously), and you shall
> > > also see this as a way to check that this is considered usefull
> > > by someone.
> > >
> > > Sam
> >
> > Hmmm. If your source is located on a read-only file-system, you
> > can't modify it. You are therefore doomed to use only "known working"
> > distributions that are known to work with all possible module
> > combinations (these don't exist). So you get to compile the kernel
> > just as a test exercise or a gimmick like; "what did you do today?..."
> > answer; "I compiled the kernel..." This seems to not be very practical
> > since the purpose of compiling the kernel was to add something or
> > fix something. Now, its just to see if it compiles.
> >
> > Different configurations are handled with different ".config"
> > files.
> >
> > I think all you did was increase the compile time by writing
> > output files to different directories than the ones currently
> > in cache. There are a lot of negatives. It would be a shame for
> > you to waste a great deal of time on something that would not
> > be accepted into the distribution. Remember the earlier `make modules`
> > where the new objects went into a separate directory with sym-links?
> > That got changed. I think it got changed for good reasons.
>
> There are plenty of other good reasons for this. Offhand:
>
> - Speeds up grepping through the source tree for things if you don't
> have to look at object files. SCCS dirs still make this a pain, I may
> hack grep -r to optionally skip them.
>
> - Guarantees that doing a build should not affect anything in the srcdir;
> this is handy when preparing release tarballs etc.
Or when you store multiple versions of the source tree using cp -rl, patch, and
same. I do not want to accidentally touch any file in hardlinked trees, since
it would screw up the file in all trees.
Currently I use separate trees for compiling, which (A) consumes more disk
space, and (B) is much slower to maintain (e.g. diff knows about hard links).
If I can compile in a separate directory, I can directly use one of the
hardlinked trees as the source tree.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.orgIn personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:29 EST