Team,
I have two questions regarding kbuild.
1, According to doc., makefile can do descending. Could make carry ascending?
2, Does old style of makefile still work (it should according to the article of "Driver porting: compiling external module")?
I was using "make -C /usr/src/linux SUBDIRS=$PWD modules". Build process at the stage 2 after primary Makefile trying to get secondary Makefile to be involved. I have fairly complicated source tree to be involved in the module build process, including descending and ascending. The main (primary) Makefile is almost down to the bottom of the tree. It is in old style and has followng content:
export TOPDIR
export CFLAGS
all : ag.o
ag.o: ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o s/sl.o
ld -r -o ag.o ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o s/sl.o
../../../../t/s/ts.o:
@echo "Making t-s"
@make -C ../../../../t/s
../../../f/c/fc.o:
@echo "Making F-C"
@make -C ../../../f/c
../../../f/i/fi.o:
@echo "Making F-I"
@make -C ../../../f/i
s/sl.o:
@echo "Making linux s-l"
@make -C s
What happend is the linux make exits after excuting the above Makefile. It did not change the directory "@make -C **" and perform futher make.
At the end of tree, a Makefile is regular like (../../../f/c/Makefile):
T_INC = -I../../../t/api -I../../../t/s
SL_INC = -I../../d/l/c
FC_INC = -I../i
TI_INC = -I../../d/api
INCLUDE_LOCAL = $(T_INC) $(SL_INC) $(FC_INC) $(TII_INC)
obj-m := fc.o
fc-objs := t1.o t2.o t3.o t4.o
EXTRA_CFLAGS := $(INCLUDE_LOCAL) -I$(TOPDIR)/drivers/scsi
Any suggestion is welcomed. If the kbuild cannot do ascending, I have to change the source tree structure but that is the least I want to do.
Many thanks!
Eddie
On Tue, Jul 29, 2003 at 02:45:35PM -0600, [email protected] wrote:
> Team,
>
> I have two questions regarding kbuild.
> 1, According to doc., makefile can do descending. Could make carry ascending?
Kbuild is not designed to support ascending, and I do not think it is
possible to tweak it to do so. If you manage to tweak kbuild to support it
do not complain if it breakes. This is not intended neither supported.
> 2, Does old style of makefile still work (it should according to the article of "Driver porting: compiling external module")?
What Corbet suggest in the referenced doc is to have the following:
ifndef KERNELRELEASE
here goes old style Makefile
else
here goes Kbuild makefile
endif
And this is _only_ the topmost makefile. And the oldstyle part is only
to make it simple to do make -C kernelsrcdir SUBDIRS=$PWD modules
kbuild does not support old-style Makefiles, but fragments are supported.
May I request you to read Documentation/kbuild/makefiles.txt - this
is an up-to-date description of what kbuild supports, and what syntax to use.
The most complex examples of use in the kernel today is some of the
arch Makefiles. Maybe they can help you?
> export TOPDIR
> export CFLAGS
>
> all : ag.o
>
> ag.o: ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o s/sl.o
> ld -r -o ag.o ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o s/sl.o
This looks really ugly. I do not expect kbuild to even get close to help
you here. kbuild is designed around the idea that objects are built
directory-by-directory, and in the upper level directory the are linked.
What you have surely does not follow that principle.
> Any suggestion is welcomed. If the kbuild cannot do ascending, I have to change the source tree structure but that is the least I want to do.
This is my best suggestion. Follow the normal way of doing things in the
kernel make it easier/possible to use the infrastructure provided
by the kernel.
PS. Please also read the paper by Kai Germashewski from OLS -
see http://www.linuxsymposium.org - it provide good background info on kbuild.
Sam
Thanks Sam and Robin!
I read kbuild/makefile.txt several times and could not find the answer fit my need. It looks like I have to change my source tree structure. I was refering to scsi/aic7xxx/ but not getting solution either. Now I am going to look into arch/Makefiles.
Appreciate your help, always!
Eddie
> -----Original Message-----
> From: Sam Ravnborg [mailto:[email protected]]
> Sent: Tuesday, July 29, 2003 2:09 PM
> To: [email protected]
> Cc: [email protected]; Kai Germaschewski
> Subject: Re: 2.5.x module make questions
>
>
> On Tue, Jul 29, 2003 at 02:45:35PM -0600,
> [email protected] wrote:
> > Team,
> >
> > I have two questions regarding kbuild.
> > 1, According to doc., makefile can do descending. Could
> make carry ascending?
> Kbuild is not designed to support ascending, and I do not think it is
> possible to tweak it to do so. If you manage to tweak kbuild
> to support it
> do not complain if it breakes. This is not intended neither supported.
>
> > 2, Does old style of makefile still work (it should
> according to the article of "Driver porting: compiling
> external module")?
>
> What Corbet suggest in the referenced doc is to have the following:
>
> ifndef KERNELRELEASE
> here goes old style Makefile
> else
> here goes Kbuild makefile
> endif
>
> And this is _only_ the topmost makefile. And the oldstyle part is only
> to make it simple to do make -C kernelsrcdir SUBDIRS=$PWD modules
> kbuild does not support old-style Makefiles, but fragments
> are supported.
>
> May I request you to read Documentation/kbuild/makefiles.txt - this
> is an up-to-date description of what kbuild supports, and
> what syntax to use.
>
> The most complex examples of use in the kernel today is some of the
> arch Makefiles. Maybe they can help you?
>
> > export TOPDIR
> > export CFLAGS
> >
> > all : ag.o
> >
> > ag.o: ../../../../t/s/ts.o ../../../f/c/fc.o
> ../../../f/i/fi.o s/sl.o
> > ld -r -o ag.o ../../../../t/s/ts.o ../../../f/c/fc.o
> ../../../f/i/fi.o s/sl.o
>
> This looks really ugly. I do not expect kbuild to even get
> close to help
> you here. kbuild is designed around the idea that objects are built
> directory-by-directory, and in the upper level directory the
> are linked.
> What you have surely does not follow that principle.
>
> > Any suggestion is welcomed. If the kbuild cannot do
> ascending, I have to change the source tree structure but
> that is the least I want to do.
>
> This is my best suggestion. Follow the normal way of doing
> things in the
> kernel make it easier/possible to use the infrastructure provided
> by the kernel.
>
> PS. Please also read the paper by Kai Germashewski from OLS -
> see http://www.linuxsymposium.org - it provide good background info
> on kbuild.
>
> Sam
>
On Tue, 2003-07-29 at 22:09, Sam Ravnborg wrote:
> What Corbet suggest in the referenced doc is to have the following:
>
> ifndef KERNELRELEASE
> here goes old style Makefile
> else
> here goes Kbuild makefile
> endif
This is pointless. The 'make -C $KERNELDIR SUBDIRS=`pwd`' form has been
working since at least 2.0, and surely nobody's trying to build for 1.3
kernels any more? Just do it the latter way unconditionally.
> > ag.o: ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o s/sl.o
> > ld -r -o ag.o ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o s/sl.o
>
> This looks really ugly. I do not expect kbuild to even get close to help
> you here. kbuild is designed around the idea that objects are built
> directory-by-directory, and in the upper level directory the are linked.
> What you have surely does not follow that principle.
In fact, the kbuild system just uses strings for the SUBDIRS variable...
it doesn't inspect them to check for '..' in them and deliberately barf
(although perhaps it should :).
ifndef TOPDIR
# Invoked from the command line... do it properly
# KERNELDIR can be overridden on the command line
KERNELDIR := /lib/modules/`uname -r`/build
default:
make -C $(KERNELDIR) SUBDIRS=`pwd` modules
else
# Invoked from the kernel build...
SUBDIRS := ../../../../t/s../../../f/c ../../../f/i s
ag-objs := ../../../../t/s/ts.o ../../../f/c/fc.o ../../../f/i/fi.o \
s/sl.o
obj-m := ag.o
endif
> > Any suggestion is welcomed. If the kbuild cannot do ascending, I have to change the source tree structure but that is the least I want to do.
>
> This is my best suggestion. Follow the normal way of doing things in the
> kernel make it easier/possible to use the infrastructure provided
> by the kernel.
>
> PS. Please also read the paper by Kai Germashewski from OLS -
> see http://www.linuxsymposium.org - it provide good background info on kbuild.
>
> Sam
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
dwmw2