Re: [kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
Kai Germaschewski wrote: You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. Can't bitkeeper be setup to have readonly files for files not checked out. I know cvs can and other configuration management tools such as Aegis (which I really like). Cheers, Brendan Simon. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
Le jeu 03/10/2002 à 04:59, Kai Germaschewski a écrit : Hi, I'd appreciate to get comments on the appended patch. It's mostly cleanups and the like, but the interesting part is the last cset, which is actually fairly small: 14 files changed, 64 insertions(+), 47 deletions(-) The build process remains recursive, but it changes the recursion from make -C subdir to make -f subdir/Makefile Could you do instead: include subdir/Makefile ? This would avoid recursive make, which isn't really a good idea (even if it's used widely). Here is a good agument about that: http://www.cse.iitb.ac.in/~soumen/teach/cs699a1999/make.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
Le jeu 03/10/2002 à 16:56, Kai Germaschewski a écrit : This would avoid recursive make, which isn't really a good idea (even if it's used widely). Here is a good agument about that: http://www.cse.iitb.ac.in/~soumen/teach/cs699a1999/make.html I think I heard that before, but I would argue that recursive builds if done right are just fine from the correctness point of view. Then I would argue that recursive builds are a tradeoff between speed/maintainability and correctness. Perhaps you should re-read this paper then. Your patches go in the right direction, though. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, 3 Oct 2002, Sam Ravnborg wrote: -obj-$(CONFIG_ACPI_INTERPRETER) := $(patsubst %.c,%.o,$(wildcard *.c)) +obj-y := dsfield.o dsmthdat.o dsopcode.o dswexec.o dswscope.o \ +dsmethod.o dsobject.o dsutils.o dswload.o dswstate.o Should that have been: obj-$(CONFIG_ACPI_INTERPRETER) := dsfield.o dsmthdat.o dsopcode.o... Looks wrong to me that you remove the CONFIG_ dependency. Same is true for the rest of this cset. No, that's fine. We only enter this subdirectory if CONFIG_ACPI_INTERPRETER is set, so we do not need to repeat the variable here. A lot of places rely on this behavior to persist, so why not use it? +ifdef list-multi +$(warning kbuild: list-multi ($(list-multi)) is obsolete in 2.5. Please fix!) +endif Since kbuild no longer support list-multi this should be $(error ) Well, since it will still work fine (throwing an additional warning later on), I think a warning is okay here. I should have made the O_TARGET one an error now, though, since that stopped working. Anyway, I'll make both of them an error in a little bit, so... SUBDIRS+= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m))) I prefer first assignment to be := not += This is true for several places including several makefiles as well. Well, really mostly a matter of taste. Using += everywhere has the advantage that you can add another line before that line without changing out. Kinda the same thing as adding a comma after the last element of a struct / enum. -export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS +export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS LDFLAGS Did not see this change justified. The export LDFLAGS just moved to a place where it's more logical. -export NETWORKS DRIVERS LIBS HEAD LDFLAGS MAKEBOOT +$(warning $(SUBDIRS)) Warning shall be deleted Right. I overlooked it first, but it's deleted in a later cset. ifndef O_TARGET ifndef L_TARGET -O_TARGET := built-in.o +O_TARGET := $(obj)/built-in.o +endif endif This change result in ld being called for directories like: $(TOPDIR)/scripts $(TOPDIR)/scripts/lxdialog $(TOPDIR)/Documentation/DocBook If obj-y is empty then do not define O_TARGET? Well, it's rather that I used EXTRA_TARGETS in those subdirs now. You're right that the standard rules do not apply in those dirs, so I'll think of a way to fix it there. Not defining O_TARGET when obj-y is empty is not an option, we rely on that case working elsewhere. Another more general comment. There seem to no consistency in the variables used in the first section of the makefile. There is a mixture of lower and upper case variables: O_TARGET, host-progs etc. This is confusing. Well, the whole thing is moving away from capitalized letters (in particular in the per-subdir Makefiles), as it is moving from old-style to new-style. The only common variables which are capitalized are CFLAGS, CC and the like, and I think they'll stay since that's standard make. kbuild-specific variables should really be basically all lower-case by now, I can only think of L_TARGET as an exception. Furthermore the construct: obj-y := some.o dot.o .o module.o Seems illogical to me. What does obj-y mean to me?? mandatory-objs := some.o dot.o .o module.o No, I think once you've understood obj-$(CONFIG_FOO), the meaning of obj-y is perfectly clear. Giving multiple names to the samt thing is not good, next thing would be people wondering what the difference between obj-y and mandatory-objs is. first_rule: $(if $(KBUILD_BUILTIN),$(O_TARGET) $(L_TARGET) $(EXTRA_TARGETS)) \ Where comes the requirement that EXTRA_TARGETS needs to be buildin? Initially, it was for built-in targets in addition to the standard O_TARGET, like arch/i386/kernel/head.o. I've been abusing it for scripts/, and I shouldn't be doing that. -cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs),$^) +cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs,$^) Keep a variable without obj appended would make this readable I think. I agree that it is not particularly readable, but I'm limited to what make offers. What do you suggest? --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, 3 Oct 2002, Sam Ravnborg wrote: On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: Now it's testing time.. [...] You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On 3 Oct 2002, Xavier Bestel wrote: Could you do instead: include subdir/Makefile ? It's not quite that easy, unfortunately ;( This would avoid recursive make, which isn't really a good idea (even if it's used widely). Here is a good agument about that: http://www.cse.iitb.ac.in/~soumen/teach/cs699a1999/make.html I think I heard that before, but I would argue that recursive builds if done right are just fine from the correctness point of view. --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 03:38:22PM -0500, Kai Germaschewski wrote: You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. Did a pull from bkbits at 18:30 CET, something like 09:30 pacific I think. In general. I like where you are heading, both the make -f, but also the cleanup done in the top-level Makefile. It makes it much easier to integrate my (ours) new make clean stuff - but that shall wait until this is in the kernel. Comments looking at the two new csets: 1) In the descend macro you test for ifeq ($(KBUILD_VERBOSE),1) To make it consistent I suggest to use ifneq ($(KBUILD_VERBOSE),0) As done earlier in the Makefile 2) Needed the following to make my kernel compile (make mrproper defconfig all) = Rules.make 1.76 vs edited = --- 1.76/Rules.make Thu Oct 3 04:51:25 2002 +++ edited/Rules.make Fri Oct 4 20:38:37 2002 @@ -161,7 +161,7 @@ # This sets version suffixes on exported symbols # --- -MODVERDIR := include/linux/modules/$(obj) +MODVERDIR := include/linux/modules # # Added the SMP separator to stop module accidents between uniprocessor @@ -191,7 +191,7 @@ # files (fix-dep filters them), so touch modversions.h if any of the .ver # files changes -quiet_cmd_cc_ver_c = MKVER include/linux/modules/$(obj)/$*.ver +quiet_cmd_cc_ver_c = MKVER include/linux/modules/$*.ver cmd_cc_ver_c = $(CPP) $(c_flags) $ | $(GENKSYMS) $(genksyms_smp_prefix) \ -k $(VERSION).$(PATCHLEVEL).$(SUBLEVEL) $@.tmp Otherwise if failed first time it included modversions.h 3) This is just to make output nicer with KBUILD_VERBOSE=0 = drivers/pci/Makefile 1.15 vs edited = --- 1.15/drivers/pci/Makefile Wed Oct 2 21:54:34 2002 +++ edited/drivers/pci/Makefile Fri Oct 4 20:59:55 2002 @@ -29,7 +29,9 @@ obj-y += syscall.o endif -host-progs := gen-devlist +host-progs := gen-devlist +quiet_cmd_gendevlist = DEVLIST $ +cmd_gendevlist= ( cd $(obj); ./gen-devlist ) $ include $(TOPDIR)/Rules.make @@ -40,6 +42,6 @@ # And that's how to generate them $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist - ( cd $(obj); ./gen-devlist ) $ + $(call cmd,gendevlist) $(obj)/classlist.h: $(obj)/devlist.h And the same for zorro: = drivers/zorro/Makefile 1.6 vs edited = --- 1.6/drivers/zorro/Makefile Wed Oct 2 21:54:34 2002 +++ edited/drivers/zorro/Makefile Fri Oct 4 21:05:54 2002 @@ -7,7 +7,9 @@ obj-$(CONFIG_ZORRO)+= zorro.o names.o obj-$(CONFIG_PROC_FS) += proc.o -host-progs := gen-devlist +host-progs := gen-devlist +quiet_cmd_gendevlist = DEVLIST $ +cmd_gendevlist = ( cd $(obj); ./gen-devlist ) $ include $(TOPDIR)/Rules.make @@ -18,4 +20,4 @@ # And that's how to generate them $(obj)/devlist.h: $(src)/zorro.ids $(obj)/gen-devlist - ( cd $(obj); ./gen-devlist ) $ + $(call cmd,gendevlist) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Wed, Oct 02, 2002 at 09:59:00PM -0500, Kai Germaschewski wrote: Hi, I'd appreciate to get comments on the appended patch. It's mostly cleanups and the like, but the interesting part is the last cset, which is actually fairly small: Tried out what I pulled from linux-2.5.make 1) warning present in Makefile 2) Annoying /././ when doing make dep 3) Did a ld built-in.o in scripts, despite obj-y is empty - When i changed = to := to fix next error ar failed. ifdef O_TARGET replaced with ifdef obj-y to make it work 4) Could not link, no *.o file were used as parameters to ld cmd_link_o_target := $(if $(strip $(obj-y)),\ $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(obj-y), $^),\ rm -f $@; $(AR) rcs $@) $(O_TARGET): $(obj-y) FORCE @echo X $^ @echo $(obj-y) - $@ Result: make[1]: Entering directory `/home/sam/src/linux/kernel/bk/kai-make/init' Generating /home/sam/src/linux/kernel/bk/kai-make/include/linux/compile.h (unchanged) X main.o version.o do_mounts.o FORCE ./main.o ./version.o ./do_mounts.o - built-in.o ld -m elf_i386 -r -o ld: unrecognized option '-o' ld: use the --help option for usage information It seems that make strips ./ in front of all .o files listed in obj-y Utilising $(filter-out FORCE,$(obj-y) did the trick for me. [sam@mars kai-make]$ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Hmmm, was the stuff present at bkbits incomplete? Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 09:26:18PM +0200, Sam Ravnborg wrote: Hmmm, was the stuff present at bkbits incomplete? Just checked, yes the attached patch was never. And fixes I think all the above. A new round of testing needed Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Wed, Oct 02, 2002 at 09:59:00PM -0500, Kai Germaschewski wrote: Hi, I'd appreciate to get comments on the appended patch. -obj-$(CONFIG_ACPI_INTERPRETER) := $(patsubst %.c,%.o,$(wildcard *.c)) +obj-y := dsfield.o dsmthdat.o dsopcode.o dswexec.o dswscope.o \ + dsmethod.o dsobject.o dsutils.o dswload.o dswstate.o Should that have been: obj-$(CONFIG_ACPI_INTERPRETER) := dsfield.o dsmthdat.o dsopcode.o... Looks wrong to me that you remove the CONFIG_ dependency. Same is true for the rest of this cset. +ifdef list-multi +$(warning kbuild: list-multi ($(list-multi)) is obsolete in 2.5. Please fix!) +endif Since kbuild no longer support list-multi this should be $(error ) -multi-used-y := $(filter-out $(list-multi),$(__multi-used-y)) Here is list-multi removed. SUBDIRS += $(patsubst %/,%,$(filter %/, $(init-y) $(init-m))) I prefer first assignment to be := not += This is true for several places including several makefiles as well. -export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS +export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS LDFLAGS Did not see this change justified. -export NETWORKS DRIVERS LIBS HEAD LDFLAGS MAKEBOOT +$(warning $(SUBDIRS)) Warning shall be deleted ifndef O_TARGET ifndef L_TARGET -O_TARGET := built-in.o +O_TARGET := $(obj)/built-in.o +endif endif This change result in ld being called for directories like: $(TOPDIR)/scripts $(TOPDIR)/scripts/lxdialog $(TOPDIR)/Documentation/DocBook If obj-y is empty then do not define O_TARGET? Another more general comment. There seem to no consistency in the variables used in the first section of the makefile. There is a mixture of lower and upper case variables: O_TARGET, host-progs etc. This is confusing. Furthermore the construct: obj-y := some.o dot.o .o module.o Seems illogical to me. What does obj-y mean to me?? mandatory-objs := some.o dot.o .o module.o It a litte longer, but occur only once (typical) per makefile. Thats not something I propose for now, more to be seen as a general comment about striving for consistency in the interface to rules.make. first_rule: $(if $(KBUILD_BUILTIN),$(O_TARGET) $(L_TARGET) $(EXTRA_TARGETS)) \ Where comes the requirement that EXTRA_TARGETS needs to be buildin? -cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs),$^) +cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs,$^) Keep a variable without obj appended would make this readable I think. Now it's testing time.. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
[Sam Ravnborg] +ifdef list-multi +$(warning kbuild: list-multi ($(list-multi)) is obsolete in 2.5. Please fix!) +endif Since kbuild no longer support list-multi this should be $(error ) Except that it is harmless. list-multi is a hint which the kbuild system no longer needs. Code with list-multi is (I believe) still compatible with today's kbuild, so there's no need to *force* a cleanup. Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: Now it's testing time.. 1) In order to make it link I had to change the following in rules.make: # If the list of objects to link is empty, just create an empty O_TARGET cmd_link_o_target = $(if $(strip $(obj-y)),\ - $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(obj-y), $^),\ + $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter-out +FORCE,$(obj-y)),\ rm -f $@; $(AR) rcs $@) Otherwise no objects were on the commandline because make strips ./ 2) Top-level Makefile still uses make -C therefore apths are relative to first subdirectory as seen here: CC udf/balloc.o CC udf/dir.o CC udf/file.o CC udf/ialloc.o 3) acpi failed to compile due to -Idrivers/acpi/include, but current directory is drivers. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 03:38:22PM -0500, Kai Germaschewski wrote: On Thu, 3 Oct 2002, Sam Ravnborg wrote: On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: Now it's testing time.. [...] You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. This time I applied the patch you sent in the mail. Checking bkbits Yep, the latest csets on bkbits fixes some of this. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Oct 02, 2002 21:59 -0500, Kai Germaschewski wrote: The build process remains recursive, but it changes the recursion from make -C subdir to make -f subdir/Makefile i.e. the current working directory remains the top dir for all times. So gcc/ld/.. are now called from the topdir, allowing to closer resemble a non-recursive build. Some Makefiles may need a little additional tweaking (in particular arch/*), but generally, the changes required are pretty small. This is nice, because if you are doing make -j[n] you currently get dumped into the wrong file (or just some non-existent file in the wrong directory) on build warnings and errors (when compiling under vim/emacs) because e.g. the make[1]: entering directory fs/ext3 message was followed by make[1]: entering directory fs/msdos, while still compiling files in fs/ext3. Granted, this isn't a great reason to change, but it bugs me every day. Cheers, Andreas -- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
