Messages in this thread |  | | From | Keith Owens <> | Subject | Re: [PATCH] net/802/Makefile | Date | Tue, 27 Nov 2001 17:28:16 +1100 |
| |
On Mon, 26 Nov 2001 22:18:55 -0800 (PST), "David S. Miller" <davem@redhat.com> wrote: > From: Keith Owens <kaos@ocs.com.au> > Date: Tue, 27 Nov 2001 17:12:04 +1100 > > The source repository (whether BK or any other system) is not the > problem. You can get the timestamps right in the source but the moment > you generate and ship a diff then you lose control of timestamps. See > the long screed below about the problems with shipping generated files, > from kbuild-2.5.txt. > >Even after reading this I don't understand why defkeymap.c gets >special treatment just because it requires external tools to generate. > >If the timestamps get messed up, it's going to try to regerenerate the >file with loadkeys whether you have it or not.
When the maintainer did the build on their system, the timestamps were right. The moment the change is converted to a patch and sent for inclusion in the kernel, timestamp order cannot be guaranteed, the final result on kernel.org may have the base file being older or newer than the generated output. kbuild 2.4 is completely broken for generated files, tthe only reason it "works" is because most of these files do not change.
kbuild 2.5 fixes this problem. It knows that you can never rely on timestamps when you ship both a base file and a file that has been generated from it. Instead it uses checksums to detect any changes, that is part of the gory details that were omitted from the previous mail.
>At best, I'd be happy to take a patch which commented out the rule >which tries to generate net/802/cl2llc.c but not one which will chmod >it. Because the latter only makes sense if we are now deciding to do >this for _every_ such case in the tree.
I have fixed _every_ such case in 2.5. It is unfixable in 2.4, the order of timestamps on generated and shipped files is not reliable.
- 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/
|  |