Messages in this thread | | | From | Peter Samuelson <> | Date | Sun, 7 Nov 1999 09:01:40 -0600 (CST) | Subject | Re: toplevel Makefile bug and simple fix |
| |
[Martijn van Oosterhout] > Actually I was thinking having all modules unpack into their own > directory with the same name. For example: mymodule-1.02.tar.gz > unpacks to mymodule-1.02 directory. My reasoning for this is that > every module will have to have a Config.in (maybe not) and some > documentation to appear when you press '?' in the config screen.
I consider that overengineering. I like the idea of being able to copy any old foo.c into the directory and have it just picked up -- no special makefile, no Config.in, just foo.c.
For modules more complex than a single .c file, a subdirectory with a Makefile makes sense. But, for example, most of Donald's network drivers are single .c files.
> > Here's my variation on the above: > > > > * Makefile in extras/ assumes that any file foo.c is a standalone > > module to be installed as foo.o in the "extras" section > Good idea, but what about docs. Header in C file?
For modules consisting of a single file, there is usually only one config option: CONFIG_FOO=m. And this is already implied by the fact that the user copied the file into the directory. Other config options are typically handled by module parameters instead.
> > * Makefile further assumes that directory bar/ is a standalone > > module to be compiled with its own Makefile; said Makefile is > > responsible for creating bar/bar.o, which will of course be > > installed in the "extras" section > Yes.
This autodetection breaks down if you use versioned dir names -- who needs bar-1.02.o? Somehow I still like having extras/Makefile take care of installation rather than extras/bar-1.02/Makefile having to do it. Perhaps extras/Makefile would look in turn for ${dirname}/${dirname}.o and ${dirname}/${dirname%-*}.o. Not sure about that one.
> See above. I think that not having the end user need to know how to > untar things would be good. OTOH, if the know how to move the file > there...
> otoh, maybe this is too easy. We're talking about kernel code here. > (Thinking kernel module virus)
Yeah, I don't know why it needs to be *totally* automatic. Anyone who can wield `cp' can wield `tar', given a README. I distrust things that untar behind my back, and I *really* distrust things that clean out old version directories behind my back. What if I made local modifications? What if I want to keep two sources around for diffing?
But either way it's a lot less hassle than driver writers have now, where they each have to write a Makefile, figure out a way to get the right -I/usr/src/... worry that if you compile the driver standalone you might not have built version.h yet, etc. (Or, like Donald does, supply a compile command for the user to cut 'n' paste.)
> Well, i think that the makefiles that come with the modules should > look similar to the ones used elsewhere in the kernel source. ie: use > M_OBJS and MI_OBJS, etc. and include ../../Rules.make This will > handle versioning and possibly installation for you.
I just don't like the idea of making bar-1.02/Makefile do anything it doesn't have to. Maybe it should include ../Rules.extra rather than the usual $(TOPDIR)/Rules.make. Then extras/Rules.extra would handle "MOD_LIST_NAME := EXTRA_MODULES" und so weiter.
-- Peter Samuelson <sampo.creighton.edu!psamuels>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |