[Philipp Rumpf <[EMAIL PROTECTED]>]
> The idea isn't bad, but I'm not sure magic comments are really the
> way to go. special macros should work just as well, shouldn't they ?
To be defined where? Do we assume everyone will #include
or something? Or #include ? It
seems a little absurd, sinc
On Fri, Oct 06, 2000 at 11:39:53PM +0200, Pavel Machek wrote:
> Well, having .in and .mak files with single lines in them seems ugly
> to me. What about make dep scanning for
>
> /* Makefile: obj-$(CONFIG_MY_DRIVER) += mydriver.o */
> /* Config.in: bool CONFIG_MY_DRIVER */
>
> i
Pavel Machek wrote:
>
> Hi!
>
> > So, when a vendor has to add a new driver, especially with the new-style
> > makefiles, you have a one-line patch to a makefile, a one-line patch to
> > a Config.in, and a patch which adds the driver to the tree.
> >
> > It would make adding new drivers to vendo
>Well, having .in and .mak files with single lines in them seems ugly
>to me. What about make dep scanning for
>
>/* Makefile: obj-$(CONFIG_MY_DRIVER) += mydriver.o */
>/* Config.in: bool CONFIG_MY_DRIVER */
>
>in .c files?
>
On Fri, 6 Oct 2000, Pavel Machek wrote:
> Well, having .in and .mak files with single lines in them seems ugly
> to me. What about make dep scanning for
>
> /* Makefile: obj-$(CONFIG_MY_DRIVER) += mydriver.o */
> /* Config.in: bool CONFIG_MY_DRIVER */
>
> in .c files?
Isn't "m
Hi!
> So, when a vendor has to add a new driver, especially with the new-style
> makefiles, you have a one-line patch to a makefile, a one-line patch to
> a Config.in, and a patch which adds the driver to the tree.
>
> It would make adding new drivers to vendor kernel packages a whole lot
> easi
6 matches
Mail list logo
