Re: Build system runs ld more often than needed

[Jean Delvare <khali@linux-fr.org>]

Hi Sam,

> > See how unrelated modules are linked again?
> 
> This is an unfortunate side-effect. Following snippet from
> scripts/Makfile.build explains it:
> 
> # We would rather have a list of rules like
> # 	foo.o: $(foo-objs)
> # but that's not so easy, so we rather make all composite objects depend
> # on the set of all their parts
> $(multi-used-y) : %.o: $(multi-objs-y) FORCE
> 	$(call if_changed,link_multi-y)
> 
> The problem is that we have no easy way to say that this specific
> module depends on this list of .o files.

OK, I see. Indeed, we had a similar problem in quilt. The kernel build
system is a bit too complex for me to propose a solution, but maybe if
I show you two rules I wrote for a similar case in the quilt Makefile,
you'll see if the same can be done for the kernel.

$(COMPAT_SYMLINKS:%=compat/%) :: Makefile
	$(call VIRTUAL_SYMLINK, \
		$($(shell echo $@ | $(AWK) '{split($$1, ar, "/"); print toupper(ar[2])}')), \
		$(strip $@))
	@chmod +x $(strip $@)

install-compat-symlink-% :: install-compat1
	ln -sf $($(shell echo $* | $(AWK) '{print toupper($$1)}'))	\
	       $(BUILD_ROOT)$(datadir)/$(PACKAGE)/compat/$*

Basically, the idea is to use awk (or any suitable tool, for that
matter) to extract and/or transform the relevant part of either the
target ($@) or the stem ($*), so as to build a variable name from it,
and then access that variable.

Given that composite targets each have an associated variable listing
the parts they must be made of, maybe it is possible to use the same
method for them? Or maybe it's too much hassle for the thin benefit,
it's up to you.

> With make 3.81 this would be possible utilising $(eval ...),
> but the benefit is too low to introduce such a dependency.

GNU make 3.80 already has $(eval ...), but having a dependency even on
3.80 is no good, agreed.

Thanks,
-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/