On Tue, 19 Feb 2008, Sam Ravnborg wrote:
> On Tue, Feb 19, 2008 at 05:15:10AM -0500, Robert P. J. Day wrote:
> > On Tue, 19 Feb 2008, Sam Ravnborg wrote:
> >
> > > On Tue, Feb 19, 2008 at 04:43:56AM -0500, Robert P. J. Day wrote:
> > > > On Mon, 18 Feb 2008, Sam Ravnborg wrote:
> > > >
> > > > > We could add something like:
> > > > > diff --git a/Makefile b/Makefile
> > > > > index 0d585c0..fb5bbc3 100644
> > > > > --- a/Makefile
> > > > > +++ b/Makefile
> > > > > @@ -358,6 +358,11 @@ export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBU
> > > > > RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS
> > > > > export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --ex
> > > > >
> > > > > +# all dirs
> > > > > +KBUILD_ALL_DIRS := arch block crypto Documentation drivers fs include init
> > > > > +KBUILD_ALL_DIRS += ipc net samples scripts security sound usr virt
> > > > > +export KBUILD_ALL_DIRS
> > > > > +
> > > >
> > > > would you not also need to include the regular files at the top of the
> > > > source tree as well? for some of the packaging targets, those files
> > > > should be included as well.
> > > Yes.
> > > 'find --max-depth=1 *' or maybe we should provide a seperate list
> > > for all the relevant filenmaes?
> >
> > oh, dang ... it just occurred to me that it's still a good idea to
> > add dirs like lost+found to the RCS_FIND_IGNORE and RCS_TAR_IGNORE
> > variables since someone might, weirdly, decide to mount a
> > subdirectory of the kernel source tree on a separate partition.
> > unlikely, yes, but it can happen.
>
> If they do I would not care at all. We should strive to make the
> normal cases behave as expected and try to come up with general
> solutions that does not prevent the more exotic cases. But trying
> to imagine all the weird cases and handle them will only result in
> an un-maintainable mess.
i agree. from what seemed like a simple fix, this has gotten a bit
out of hand. i think the easiest solution would be to just come up
with a single whitelist, and a number of command-specific blacklists,
and leave it at that. that's guaranteed to work, and it's trivially
extensible.
so, as an example, define the global whitelist:
KBUILD_ALL_FILES := COPYING CREDITS Kbuild MAINTAINERS Makefile README REPORTING-BUGS
KBUILD_ALL_DIRS := arch block crypto Documentation drivers fs include init ipc
KBUILD_ALL_DIRS += kernel lib mm net samples scripts security sound usr virt
KBUILD_ALL SRCS := $(KBUILD_ALL_FILES) $(KBUILD_ALL_DIRS)
export KBUILD_ALL_FILES KBUILD_ALL_DIRS KBUILD_ALL_SRCS
those variables above are valid for everything and are easily
augmented.
in terms of what are currently called RCS_FIND_IGNORE and
RCS_TAR_IGNORE, scrap those entirely as they clearly reflect only
"rcs"-related objects, and just invent new variables:
FIND_OBJS_TO_IGNORE := ... both files and dirs ...
TAR_OBJS_TO_IGNORE := ... both files and dirs ...
and that's it. problem solved. don't try to partition off the
RCS-related stuff into its own list of objects, it's not worth the
trouble. and note how that entirely solves the lost+found issue, and
any other issues that might ever arise.
thoughts?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
