From: "willy tarreau" <wtarreau@yahoo.fr>
To: Keith Owens <kaos@ocs.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Did someone try to boot 2.4.16 on a 386 ? [SOLVED]
Date: Sat, 1 Dec 2001 10:11:40 +0100 (CET) [thread overview]
Message-ID: <20011201091140.62223.qmail@web20502.mail.yahoo.com> (raw)
In-Reply-To: <11661.1007177721@ocs3.intra.ocs.com.au>
> A perfect example of why having the same tree for
> source and generated files and using cp -al is a
> bad idea. cp -al picks up both source and
> objects and you have to hope that anything that is
> overwritten is hard link safe (I can tell you now
> that it is not).
well, at least I only duplicate clean sources before
applying a patch. So there is absolutely no shared
object. It's just that when I try patches, I have
about 20 source trees and it's cool to have the
ability to navigate through versions without having
to store 3 GB. Moreover, diff -urN is much faster
this way. But it true that this is a "use at your own
risk".
> kbuild 2.5 allows multiple builds from the same
> source tree into separate object trees
> with different configs and is safe.
Interesting, I think I'll definitely take a look at
it.
> >I'll check around to see if there are other parts
> >which risk to modify a file on disk without
> previously
> >unlink it.
>
> Any Makefile that does "some_command > target_file"
> or runs a utility that does open(O_TRUNC) instead
> of unlink(), open(O_EXCL).
there was such an example in the past with aicasm.
Anyway, I think that any tool, script or Makefile
that modifies the source tree and which results in
a diff between the two trees after a "make distclean"
is at risk because it can induce diffs between some
files that can't always apply to another clean tree.
> BTW, cp -al of a pristine source tree to multiple
> source trees followed by multiple compiles in
> parallel is not safe either. make dep relies on
> changing time stamps for include files, because
> the include files are hard linked, a change in
> one compile affects the other trees, with
> undefined results. Also fixed in kbuild 2.5.
Never needed to do that yet.
Regards,
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Courrier : http://courrier.yahoo.fr
next prev parent reply other threads:[~2001-12-01 9:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-01 0:42 willy tarreau
2001-12-01 3:35 ` Keith Owens
2001-12-01 9:11 ` willy tarreau [this message]
2001-12-01 9:29 ` Keith Owens
2001-12-01 9:47 ` willy tarreau
2001-12-01 10:24 ` Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011201091140.62223.qmail@web20502.mail.yahoo.com \
--to=wtarreau@yahoo.fr \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®