Re: libata update posted

Jeff Garzik
2003-09-14T20:10:03Z

Andries Brouwer wrote:
> On Sun, Sep 14, 2003 at 01:26:21PM -0400, Jeff Garzik wrote:
>
>
>>>This shows why defkeymap.c is not generated in the kernel build
>>>but distributed.
>>
>>There is a difference between distributing generated files, and checking
>>generated files into a repository... I do not advocate changing the
>>tarball, just the BK repo behind it.
>
>
> So you would like to remove defkeymap.c from the bitkeeper repository.
> Can you briefly explain why?
> I am not a bk user so have no feeling for what one would like bk to do.
>
> But it seems to me that if defkeymap.c is only a generated file when
> no kbd headers have changed, while in the opposite case one needs a
> private version of loadkeys until the next version of kbd has been
> distributed, it is easier to regard it as part of the kernel source.

defkeymap.c is _always_ a generated file. However, some environments
lack the capability to generate it (properly).

My motivation is not bitkeeper-specific: I dislike the practice of
checking build-generated files into an SCM of any sort. That sort of
stuff should be handled by the maintainer, when generating the release
patches and tarballs. aic7xxx is another example

Package developers (read: kernel hackers) are expected to have a correct
environment to rebuild generated files properly. Package builders are
only expected to have a minimal build environment, with stuff like
configure scripts, yacc/lex output, defkeymap, and similar things
pre-generated from a canonical source (the maintainer).

The GNOME guys recognized this distinction between hackers and builders
a long time ago. When you check things out of GNOME cvs, you get _just_
the sources. One must run ./autogen.sh to generate the
autoconf/automake/libtool junk needed to actually build successfully.

Jeff