> So what?  Users want filenames with ',' in them, the build system
> should cope with it.  Restricting what the user is allowed to do to
> what the build system can handle is the wrong approach.  The build
> system already has to replace '-' with '_', changing comma as well is
> not a problem.  Or are you going to say that '-' is not allowed in
> filenames either?
It's a stupid discussion - I added support for filenames containing a ',', 
but the only remaining user is 53c7,8xx.c. That one is broken by the BIO 
changes anyway, and I heard people say it should go away, as the 
hardware is supported by other drivers. So I'll wait and see, if it 
doesn't get fixed but removed, I think removing the hacks to support ',' 
in the filename is the way to go.
> >Now, what if we had:
> > 
> > 	foo,bar.c
> > 
> > and
> > 
> > 	foo_bar.c
> > 
> > in the same directory?  The kbuild system goes wrong, destroying dependency
> > information, using the wrong KBUILD_BASENAME.  Oops.  I guess we papered
> > over a bug by allowing commas in filenames.
> 
> Not in kbuild 2.5.  I handle this case correctly for the -MD dependency
> filename.  Try it and see.
Well, let me rephrase it as "foo,bar.c" and "foo:bar.c" ;). kbuild-2.5
would break. Of course it's fixable with even more workarounds, but that's
not the point.
> OBJECTNAME is externally visible, it is used in Rusty's rationalization
> of boot and module parameters.  The only time that OBJECTNAME collision
> would be a problem is when there are two modules called foo,bar and
> foo_bar.  Having two modules that differ by a single character in the
> middle of the name is going to cause more problems than just option
> collision.  BTW, the existing build system does not support
> KBUILD_OBJECTNAME so Rusty's code cannot go in.
Rusty knows that the current build system can support KBUILD_OBJECT (which 
is what you called it, not KBUILD_OBJECTNAME) just fine - it's a three 
line diff, but I don't see a point in submitting it as long as nobody uses 
it.
--Kai
-
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/