On Mon, Mar 01, 2004 at 12:51:50AM +0100, Matthias Andree wrote:
> Hi,
>
> I've just seen, after a BK pull:
>
> CC fs/nfsd/nfsctl.o
> fs/nfsd/nfsctl.c:28:30: linux/nfsd_idmap.h: no such file or directory
>
> This is a hint the dependency information isn't complete, otherwise, GNU
> make would've "get"^Wgot the include file.
>
> Will the kernel rebuild dependent files when includes change when this
> information is missing? If so, how?
kbuild scans for dependencies and build the output file in one go.
Therefore from a make perspective it will not see the new dependency of
nfsd_idmap.h when starting to compile nfsctl.c.
Dependencies are first OK after first kernel compile.
So if you tried twice the 'bk get' functionality should be OK.
Sam
On Mon, 2004-03-01 at 01:08, Sam Ravnborg wrote:
> On Mon, Mar 01, 2004 at 12:51:50AM +0100, Matthias Andree wrote:
> > Will the kernel rebuild dependent files when includes change when this
> > information is missing? If so, how?
>
> kbuild scans for dependencies and build the output file in one go.
> Therefore from a make perspective it will not see the new dependency of
> nfsd_idmap.h when starting to compile nfsctl.c.
>
> Dependencies are first OK after first kernel compile.
> So if you tried twice the 'bk get' functionality should be OK.
Also, the changesets at bk://typhoon.bkbits.net/autoget-2.5 add
functionality to kbuild to checkout needed files automatically, as the
build progresses -- no more 'bk get' needed...
I haven't kept it up to date, but I doubt it'd need many changes to work
with a recent kernel. It's currently BK/SCCS specific, but I do not
think it would be hard to make it work with other version control
systems, as long as make supports them.
Since you do so much in kbuild, I'd love some comments on it, if you
have time.
--
Dave Dillow <[email protected]>
On Mon, Mar 01, 2004 at 12:52:08PM -0500, Dave Dillow wrote:
>
> Also, the changesets at bk://typhoon.bkbits.net/autoget-2.5 add
> functionality to kbuild to checkout needed files automatically, as the
> build progresses -- no more 'bk get' needed...
>
> I haven't kept it up to date, but I doubt it'd need many changes to work
> with a recent kernel. It's currently BK/SCCS specific, but I do not
> think it would be hard to make it work with other version control
> systems, as long as make supports them.
>
> Since you do so much in kbuild, I'd love some comments on it, if you
> have time.
I have pulled the tree, and the getfiles script and Makefile.repo is easy to spot.
Could you drop a mail with the rest of your changes as a regular patch?
I will then try to look through what you made - but my first impression is that this
is by far too much overhead just to replace an "bk -r co -Sq".
Sam
On Tue, 2004-03-02 at 13:07, Sam Ravnborg wrote:
> I have pulled the tree, and the getfiles script and Makefile.repo is easy to spot.
> Could you drop a mail with the rest of your changes as a regular patch?
Here's three patches, in order. The first adds getfiles and
Makefile.repo. It will pull all files needed from BK, except for the
Kconfig files.
The second adds support for Kconfig files.
The third is just some comsetic cleanups to cut chatter during
non-verbose builds.
> I will then try to look through what you made - but my first impression is that this
> is by far too much overhead just to replace an "bk -r co -Sq".
There is a bit of overhead, but mainly for files that are not there. If
the file has already been checked out, and the SCCS file is not newer,
then getfiles will not be run. There is the matter of an extra stat()
call, though, to figure that out.
For me, since I am working in a NFS directory, this is much faster than
doing a "bk -r get; make bzImage" because it only pulls the files needed
to build my kernel configuration. Even on a local disk, it "feels"
faster, though I'm sure I do not see as much of a benefit.
Code wise, yeah, it is more overhead, and it could be potentially
fragile in regards to compiler messages in the getfiles script.
--
Dave Dillow <[email protected]>