All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: "Michael S. Tsirkin" <mst@mellanox.co.il>
Cc: linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net,
	zippel@linux-m68k.org
Subject: Re: [PATCH] split UTS_RELEASE to a separate header.
Date: Sun, 16 Jan 2005 17:58:32 -0500	[thread overview]
Message-ID: <41EAF198.1020501@didntduck.org> (raw)
In-Reply-To: <20050116200046.GB5276@mellanox.co.il>

Michael S. Tsirkin wrote:
> Hello!
> Quoting r. Sam Ravnborg (sam@ravnborg.org) "Re: changing local version requires full rebuild":
> 
>>On Sun, Jan 16, 2005 at 05:22:42PM +0200, Michael S. Tsirkin wrote:
>>
>>>Hi!
>>>Is it just me, or does changing the local version always require
>>>a full kernel rebuild?
>>>
>>>If so, I'd like to fix it, since I like copying
>>>my kernel source with --preserve and changing the
>>>local version, then going back to the old version in case of
>>>a crash.
>>>Its important to change the local version to force 
>>>make install and make modules_install to put things in a separate
>>>directory.
>>
>>Just tried it out here.
>>After cp -Ra only a limited part of the kernel rebuilds.
>>o oiu.c in ieee directory - because it dependson the shell script
>>o A number of drivers that include version.h
>>	- This should be changed so local version does not affect
>>	  the reast of version.h.
>>o Other stuff that is always build if kernel has changed
>>
>>Do you use "echo -mylocalver > localversion" to change the local version?
>>
>>	Sam
> 
> 
> Well, we have
> /usr/src/linux-2.6.10-gold # grep -l UTS_RELEASE -rI . | wc -l
> 29
> grep -l version.h -rI . | fgrep -v .cmd | fgrep -v '.mod' | fgrep -e '.c' -e '.h' | wc -l
> 354
> 
> This means that about 300 files are compiled each time localversion changes,
> which do not actually use the local version.
> 
> So, let us split UTS_RELEASE to a separate header: release.h
> The following patch over 2.6.10 does that, and fixed the in-tree files that
> really need to include it.
> Works for me, and helps me cut down compilation time. Comments?
> 

Most of the stuff using UTS_RELEASE can use system_utsname.release 
instead (except boot code).  Most cases in drivers/ can simply be removed.

--
				Brian Gerst

      reply	other threads:[~2005-01-16 22:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-16 15:22 changing local version requires full rebuild Michael S. Tsirkin
2005-01-16 16:16 ` Sam Ravnborg
2005-01-16 16:28   ` Michael S. Tsirkin
2005-01-16 17:26     ` Sam Ravnborg
2005-01-16 17:55       ` Michael S. Tsirkin
2005-01-16 19:42       ` Michael S. Tsirkin
2005-01-16 17:24   ` Michael S. Tsirkin
2005-01-16 18:11   ` Michael S. Tsirkin
2005-01-16 20:00   ` [PATCH] split UTS_RELEASE to a separate header Michael S. Tsirkin
2005-01-16 22:58     ` Brian Gerst [this message]

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=41EAF198.1020501@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=kbuild-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@mellanox.co.il \
    --cc=zippel@linux-m68k.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.