Robert P. J. Day wrote: > first, i notice that, if i run "make romfs", the subdirs that will > be processed are defined by: > > DIRS = $(VENDOR_TOPDIRS) include lib include user > > but WRT to making romfs/, what is the value of processing the include/ > directory? the file include/Makefile defines a completely empty > "romfs" target so, while it clearly doesn't hurt, it seems pointless > to even enter the include/ directory when processing the "romfs" > target.
DIRS is used for other targets too. > also, just to be clear, is the purpose of "make romfs" in general to > create and populate the directory romfs/ with its final contents. i > ask since the romfs target is defined thusly: Yes. > .PHONY: romfs > romfs: romfs.newlog romfs.subdirs modules_install romfs.post > > and romfs.post is defined as: > > .PHONY: romfs.post > romfs.post: > $(MAKEARCH) -C vendors romfs.post > -find $(ROMFSDIR)/. -name CVS | xargs -r rm -rf > . $(LINUXDIR)/.config; if [ "$$CONFIG_INITRAMFS_SOURCE" != "" ]; then > \ > $(MAKEARCH_KERNEL) -j$(HOST_NCPU) -C $(LINUXDIR) > $(LINUXTARGET) || exit 1; \ > fi > > now, while configuring the kernel and building it based on > CONFIG_INITRAMFS_SOURCE is certainly an important step in the *final* > construction of the initramfs image, i don't see what it has to do > with the romfs step. quite simply, it looks out of place. unless > there's something unusual happening here, i would think that it's not > the romfs target's responsibility to do that kernel step -- that > should be left for the final initramfs image creation step, no? It's out of place for both of them. It should have been done as part of 'make linux', but we didn't have the romfs yet at that point, so this is the earliest it could be done. Moving it to the 'make image' step would be an option, but not sure it matters really. One small advantage to leaving it in the romfs step is that doing 'make linux image' avoids some unnecessary work. _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
