lkml.org 
[lkml]   [2002]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/CFT] Separate obj/src dir
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.org

In 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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.070 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site