Introduced in 2.4.4pre4, I believe. $(export-objs) need not be
conditional, and the if statement was not really correct either,
although in this case it probably worked.
Peter
--- 2.4.4pre6/lib/Makefile~ Mon Apr 23 09:51:17 2001
+++ 2.4.4pre6/lib/Makefile Mon Apr 23 17:11:04 2001
@@ -8,14 +8,12 @@
L_TARGET := lib.a
-export-objs := cmdline.o
+export-objs := cmdline.o rwsem.o
obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o
-ifneq ($(CONFIG_RWSEM_GENERIC_SPINLOCK)$(CONFIG_RWSEM_XCHGADD_ALGORITHM),nn)
-export-objs += rwsem.o
-obj-y += rwsem.o
-endif
+obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem.o
+obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
obj-y += dec_and_lock.o
On Mon, Apr 23, 2001 at 05:16:24PM -0500, Peter Samuelson wrote:
> Introduced in 2.4.4pre4, I believe. $(export-objs) need not be
> conditional, and the if statement was not really correct either,
> although in this case it probably worked.
Er, are you sure changing the test for !"nn" is correct here?
I _think_ at least that is intentional and correct (since you can have
one on but not the other).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
[Peter Samuelson]
> > Introduced in 2.4.4pre4, I believe. $(export-objs) need not be
> > conditional, and the if statement was not really correct either,
> > although in this case it probably worked.
[Tom Rini]
> Er, are you sure changing the test for !"nn" is correct here? I
> _think_ at least that is intentional and correct (since you can have
> one on but not the other).
I understand the intent. The point is that in our current makefiles
you are not allowed to assume that a negative value is "n", because it
could be "".
2.4.4pre probably works because each 'config.in' file explicitly sets
these variables to "y" or "n". However, it would be perfectly legal
for a config.in to unset the variable, or for that matter not even
mention it. In that case the !"nn" test fails.
This is the same reason you cannot use 'ifdef CONFIG_*' in the
Makefiles. Lots of people do, but each instance is a bug. They are
assuming the opposite: that a variable will be "" rather than "n".
(N.B. this issue will go away with Keith's 2.5 Makefiles. And there
was much rejoicing.)
Peter