linux-2.5.24/drivers/net/hamradio/soundmodem/Makefile contains
the following rule:
$(obj)/sm_tbl_%: $(obj)/gentbl
$<
obj was set to "." /usr/src/linux/Rules.make, which was included
earlier in the Makefile.
The problem is that when make executes this rule it executes
"gentbl" rather than "./gentbl". This causes the command to fail if
you do not have "." in your path. Make-3.79.1 is apparently being too
clever in expanding file names. I think this is a make bug.
Until the make bug is fixed, I have worked around the problem
by replacing the rule with:
$(obj)/sm_tbl_%: $(obj)/gentbl
PATH=$(obj):$$PATH $<
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
Scripsit "Adam J. Richter" <[email protected]>
[Warning: I am not the make maintainer; I just lurk on bug-make]
> $(obj)/sm_tbl_%: $(obj)/gentbl
> $<
> obj was set to "." /usr/src/linux/Rules.make, which was included
> earlier in the Makefile.
> Until the make bug is fixed, I have worked around the problem
> by replacing the rule with:
> $(obj)/sm_tbl_%: $(obj)/gentbl
> PATH=$(obj):$$PATH $<
That looks like an excessively complicated workaround. Why not just
$(obj)/sm_tbl_%: $(obj)/gentbl
$(obj)/gentbl
?
I'm not sure this is really a bug either. It is a Good Thing that make
tries to normalize the names of targets and dependencies internally,
lest the build may be incomplete or redundant if make does not realize
that foo.bar and ./foo.bar is the same file. It is quite reasonable
for $< to unfold to the *canonical* name of the file in question, I
think.
If one absolutely wants the command to use the exact form of the
dependency that's used in the dependency list, it's easy to simply
reproduce that form, replacing the % by $*
--
Henning Makholm "You are in a little twisting
maze of passages, all different"
Hi Henning.
> [Warning: I am not the make maintainer; I just lurk on bug-make]
Fair warning...
>> $(obj)/sm_tbl_%: $(obj)/gentbl
>> $<
>>
>> obj was set to "." in /usr/src/linux/Rules.make, which was included
>> earlier in the Makefile.
>>
>> Until the make bug is fixed, I have worked around the problem
>> by replacing the rule with:
>>
>> $(obj)/sm_tbl_%: $(obj)/gentbl
>> PATH=$(obj):$$PATH $<
> That looks like an excessively complicated workaround. Why not just
>
> $(obj)/sm_tbl_%: $(obj)/gentbl
> $(obj)/gentbl
>
> instead ?
I'm no expert on Makefile syntax, but I am aware of one possible
difference between those two versions with SOME versions of Make and
I believe this Makefile has been carefully crafted to work with all
versions thereof.
The difference will only show up if $(obj) expands to a string with
spaces in it, generated by a definition such as...
obj = `pwd`
...due to a difference in how SOME versions of Make handle that. My
experience has been that all versions of Make expand "dependency" tokens
as a single token, and copy them down as a single token when $< or the
like are used, but expand the $(obj) in the command line as multiple
tokens in that case. As an example, say that your version of that
definition had been used with the obj=`pwd` definition when the current
directory was "/home/michael/source files/ax25" and we see that the
dependency is correctly interpreted as...
"/home/michael/source files/ax25/gentbl"
...but the command that follows is taken as being...
/home/michael/source
...with a parameter of...
files/ax25/gentbl
...which is clearly not what was intended.
> I'm not sure this is really a bug either.
It's a genuine bug that needs fixing.
> It is a Good Thing that make tries to normalize the names of targets
> and dependencies internally, lest the build may be incomplete or
> redundant if make does not realize that foo.bar and ./foo.bar is the
> same file.
Providing "internally" relates only to internal transliterations done on
the files listed on the dependency line for the purpose of determining
whether a particular file is up to date, and does not also relate to the
use of those files in the rules that follow, there's no problem there.
However, using ANY sort of transliteration with commands listed below
those lines is completely counter-intuitive, and
> It is quite reasonable for $< to unfold to the *canonical* name of
> the file in question, I think.
The ONLY reasonable canonical name for ANY file is that which includes
the full path to that file starting from the root directory and working
down through real directories without encountering any symbolic links.
Absolutely anything else is open to misinterpretation.
> If one absolutely wants the command to use the exact form of the
> dependency that's used in the dependency list, it's easy to simply
> reproduce that form, replacing the % by $*
By doing so, one introduces unacceptable bugs in many cases, simply due
to differing treatment of the two cases by different versions of make.
Best wishes from Riley.
Scripsit Riley Williams <[email protected]>
> >> $(obj)/sm_tbl_%: $(obj)/gentbl
> >> PATH=$(obj):$$PATH $<
> > That looks like an excessively complicated workaround. Why not just
> > $(obj)/sm_tbl_%: $(obj)/gentbl
> > $(obj)/gentbl
> The difference will only show up if $(obj) expands to a string with
> spaces in it, generated by a definition such as...
> obj = `pwd`
In which case the command
PATH=$(obj):$$PATH $<
is likely do fail miserably too.
Also, the dependency list $(obj)/gentbl will be parsed as multiple
files when $(obj) contains spaces. Which is clearly the right
behavior, as it is hard to find a serious project that does not use
Makefile variables to hold the names of multiple dependencies
somewhere.
> ...due to a difference in how SOME versions of Make handle that. My
> experience has been that all versions of Make expand "dependency" tokens
> as a single token, and copy them down as a single token when $< or the
> like are used, but expand the $(obj) in the command line as multiple
> tokens in that case.
If one is afraid of that, one can use
"$(obj)/gentbl"
which will prevent the shell from thinking that the space separates
"words" on the command line. (Whether one can trick make into
interpreting the space as part of the filename in the dependency list
is another matter).
> > I'm not sure this is really a bug either.
> It's a genuine bug that needs fixing.
I still disagree.
> Providing "internally" relates only to internal transliterations done on
> the files listed on the dependency line for the purpose of determining
> whether a particular file is up to date, and does not also relate to the
> use of those files in the rules that follow, there's no problem there.
I don't think that "$<" is documented anywhere to have any exact
relationship to the string of characters used in the depencency
list. The GNU make manual says that $< is "the name of the first
depencency", not "the string used to identify the first dependency in
the rule".
> The ONLY reasonable canonical name for ANY file is that which includes
> the full path to that file starting from the root directory and working
> down through real directories without encountering any symbolic links.
> Absolutely anything else is open to misinterpretation.
Assuming anything for $< (and similar variables) but that they unfold
to SOME name that references the file in question, is open to
misinterpretation and leads to unportable makefiles.
--
Henning Makholm "... and that Greek, Thucydides"
Scripsit "Adam J. Richter" <[email protected]>
> >I'm not sure this is really a bug either. It is a Good Thing that make
> >tries to normalize the names of targets and dependencies internally,
> >lest the build may be incomplete or redundant if make does not realize
> >that foo.bar and ./foo.bar is the same file. It is quite reasonable
> >for $< to unfold to the *canonical* name of the file in question, I
> >think.
> That just makes the behavior of make less predictable.
> Whatever make does with the file names internally is its own business.
> Rewriting the file names passed to commands unnecessarily is
> potentially a big problem.
It is not rewriting file names. It is just substituting the name of
the dependency for the $< variable, just as documented.
> >If one absolutely wants the command to use the exact form of the
> >dependency that's used in the dependency list, it's easy to simply
> >reproduce that form, replacing the % by $*
> Sorry, I do not understand what you mean.
It wasn't right anyway. I remembered the semantics of $* when the file
name contains slashes wrong.
--
Henning Makholm "They are trying to prove a hypothesis,
they are down here gathering data every season,
they're publishing results in peer-reviewed journals.
They're wrong, I think, but they are still scientists."
--- linux-2.5.24/drivers/net/hamradio/Config.in.sm Mon Jun 24 17:22:03 2002
+++ linux-2.5.24/drivers/net/hamradio/Config.in Mon Jun 24 17:22:44 2002
@@ -18,18 +18,5 @@
dep_tristate 'BAYCOM picpar and par96 driver for AX.25' CONFIG_BAYCOM_PAR $CONFIG_PARPORT $CONFIG_AX25
dep_tristate 'BAYCOM epp driver for AX.25' CONFIG_BAYCOM_EPP $CONFIG_PARPORT $CONFIG_AX25
-dep_tristate 'Soundcard modem driver' CONFIG_SOUNDMODEM $CONFIG_PARPORT $CONFIG_AX25
-if [ "$CONFIG_SOUNDMODEM" != "n" ]; then
- bool ' soundmodem support for Soundblaster and compatible cards' CONFIG_SOUNDMODEM_SBC
- bool ' soundmodem support for WSS and Crystal cards' CONFIG_SOUNDMODEM_WSS
- bool ' soundmodem support for 1200 baud AFSK modulation' CONFIG_SOUNDMODEM_AFSK1200
- bool ' soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)' CONFIG_SOUNDMODEM_AFSK2400_7
- bool ' soundmodem support for 2400 baud AFSK modulation (8MHz crystal)' CONFIG_SOUNDMODEM_AFSK2400_8
- bool ' soundmodem support for 2666 baud AFSK modulation' CONFIG_SOUNDMODEM_AFSK2666
- bool ' soundmodem support for 4800 baud HAPN-1 modulation' CONFIG_SOUNDMODEM_HAPN4800
- bool ' soundmodem support for 4800 baud PSK modulation' CONFIG_SOUNDMODEM_PSK4800
- bool ' soundmodem support for 9600 baud FSK G3RUH modulation' CONFIG_SOUNDMODEM_FSK9600
-fi
-
dep_tristate 'YAM driver for AX.25' CONFIG_YAM $CONFIG_AX25
--- linux-2.5.24/drivers/net/hamradio/Makefile.sm Mon Jun 24 17:22:07 2002
+++ linux-2.5.24/drivers/net/hamradio/Makefile Mon Jun 24 17:22:30 2002
@@ -22,6 +22,5 @@
obj-$(CONFIG_BAYCOM_SER_HDX) += baycom_ser_hdx.o hdlcdrv.o
obj-$(CONFIG_BAYCOM_PAR) += baycom_par.o hdlcdrv.o
obj-$(CONFIG_BAYCOM_EPP) += baycom_epp.o hdlcdrv.o
-obj-$(CONFIG_SOUNDMODEM) += soundmodem/ hdlcdrv.o
include $(TOPDIR)/Rules.make
--- linux-2.5.24/drivers/net/hamradio/Config.help.sm Mon Jun 24 17:23:49 2002
+++ linux-2.5.24/drivers/net/hamradio/Config.help Mon Jun 24 17:24:13 2002
@@ -161,87 +161,3 @@
say M here and read <file:Documentation/modules.txt>. This is
recommended. The module will be called baycom_ser_hdx.o.
-CONFIG_SOUNDMODEM
- This experimental driver allows a standard Sound Blaster or
- WindowsSoundSystem compatible sound card to be used as a packet
- radio modem (NOT as a telephone modem!), to send digital traffic
- over amateur radio.
-
- To configure the driver, use the sethdlc, smdiag and smmixer
- utilities available in the standard ax25 utilities package. For
- information on how to key the transmitter, see
- <http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html> and
- <file:Documentation/networking/soundmodem.txt>.
-
- If you want to compile this driver as a module ( = code which can be
- inserted in and removed from the running kernel whenever you want),
- say M here and read <file:Documentation/modules.txt>. This is
- recommended. The module will be called soundmodem.o.
-
-CONFIG_SOUNDMODEM_SBC
- This option enables the soundmodem driver to use Sound Blaster and
- compatible cards. If you have a dual mode card (i.e. a WSS cards
- with a Sound Blaster emulation) you should say N here and Y to
- "Sound card modem support for WSS and Crystal cards", below, because
- this usually results in better performance. This option also
- supports SB16/32/64 in full-duplex mode.
-
-CONFIG_SOUNDMODEM_WSS
- This option enables the soundmodem driver to use WindowsSoundSystem
- compatible cards. These cards feature a codec chip from either
- Analog Devices (such as AD1848, AD1845, AD1812) or Crystal
- Semiconductors (such as CS4248, CS423x). This option also supports
- the WSS full-duplex operation which currently works with Crystal
- CS423x chips. If you don't need full-duplex operation, do not enable
- it to save performance.
-
-CONFIG_SOUNDMODEM_AFSK1200
- This option enables the soundmodem driver 1200 baud AFSK modem,
- compatible to popular modems using TCM3105 or AM7911. The
- demodulator requires about 12% of the CPU power of a Pentium 75 CPU
- per channel.
-
-CONFIG_SOUNDMODEM_AFSK2400_7
- This option enables the soundmodem driver 2400 baud AFSK modem,
- compatible to TCM3105 modems (over-)clocked with a 7.3728MHz
- crystal. Note that the availability of this driver does _not_ imply
- that I recommend building such links. It is only here since users
- especially in eastern Europe have asked me to do so. In fact this
- modulation scheme has many disadvantages, mainly its incompatibility
- with many transceiver designs and the fact that the TCM3105 (if
- used) is operated widely outside its specifications.
-
-CONFIG_SOUNDMODEM_AFSK2400_8
- This option enables the soundmodem driver 2400 baud AFSK modem,
- compatible to TCM3105 modems (over-)clocked with an 8MHz crystal.
- Note that the availability of this driver does _not_ imply that I
- recommend building such links. It is only here since users
- especially in eastern Europe have asked me to do so. In fact this
- modulation scheme has many disadvantages, mainly its incompatibility
- with many transceiver designs and the fact that the TCM3105 (if
- used) is operated widely outside its specifications.
-
-CONFIG_SOUNDMODEM_AFSK2666
- This option enables the soundmodem driver 2666 baud AFSK modem.
- This modem is experimental, and not compatible to anything
- else I know of.
-
-CONFIG_SOUNDMODEM_PSK4800
- This option enables the soundmodem driver 4800 baud 8PSK modem.
- This modem is experimental, and not compatible to anything
- else I know of.
-
-CONFIG_SOUNDMODEM_HAPN4800
- This option enables the soundmodem driver 4800 baud HAPN-1
- compatible modem. This modulation seems to be widely used 'down
- under' and in the Netherlands. Here, nobody uses it, so I could not
- test if it works. It is compatible to itself, however :-)
-
-CONFIG_SOUNDMODEM_FSK9600
- This option enables the soundmodem driver 9600 baud FSK modem,
- compatible to the G3RUH standard. The demodulator requires about 4%
- of the CPU power of a Pentium 75 CPU per channel. You can say Y to
- both 1200 baud AFSK and 9600 baud FSK if you want (but obviously you
- can only use one protocol at a time, depending on what the other end
- can understand).
-
--- linux-2.5.24/Makefile.sm Mon Jun 24 17:23:00 2002
+++ linux-2.5.24/Makefile Mon Jun 24 17:23:20 2002
@@ -599,10 +599,6 @@
# files removed with 'make mrproper'
MRPROPER_FILES += \
include/linux/autoconf.h include/linux/version.h \
- drivers/net/hamradio/soundmodem/sm_tbl_{afsk1200,afsk2666,fsk9600}.h \
- drivers/net/hamradio/soundmodem/sm_tbl_{hapn4800,psk4800}.h \
- drivers/net/hamradio/soundmodem/sm_tbl_{afsk2400_7,afsk2400_8}.h \
- drivers/net/hamradio/soundmodem/gentbl \
sound/oss/*_boot.h sound/oss/.*.boot \
sound/oss/msndinit.c \
sound/oss/msndperm.c \
On Sat, 22 Jun 2002, Riley Williams wrote:
> >> $(obj)/sm_tbl_%: $(obj)/gentbl
> >> PATH=$(obj):$$PATH $<
>
> > That looks like an excessively complicated workaround. Why not just
> >
> > $(obj)/sm_tbl_%: $(obj)/gentbl
> > $(obj)/gentbl
> >
> > instead ?
I think I like the latter better as well. Anyway, $(obj) is just "."
currently, so it doesn't have a space in it. For $(src), I'll always use
relative paths, so there won't be any spaces in them either. I think it's
a sensible restriction for separate src/obj trees to disallow spaces in
the obj tree path, I fear it'd cause problems at a huge number of places.
At least it's certainly acceptable to do "no space" first and then see
what needs to be done in order to remove that restriction.
(I also think the two are functionally equivalent even if $(obj) contains
a space, but I haven't tried at all)
--Kai
enning Makholm wrote:
>Scripsit "Adam J. Richter" <[email protected]>
>> Until the make bug is fixed, I have worked around the problem
>> by replacing the rule with:
>> $(obj)/sm_tbl_%: $(obj)/gentbl
>> PATH=$(obj):$$PATH $<
>That looks like an excessively complicated workaround. Why not just
>$(obj)/sm_tbl_%: $(obj)/gentbl
> $(obj)/gentbl
Thanks. That is a cleaner workaround.
>I'm not sure this is really a bug either. It is a Good Thing that make
>tries to normalize the names of targets and dependencies internally,
>lest the build may be incomplete or redundant if make does not realize
>that foo.bar and ./foo.bar is the same file. It is quite reasonable
>for $< to unfold to the *canonical* name of the file in question, I
>think.
That just makes the behavior of make less predictable.
Whatever make does with the file names internally is its own business.
Rewriting the file names passed to commands unnecessarily is
potentially a big problem. Suppose, for example, that this was a
command that wanted to chop up the directory prefix and that the
bottom level directory was a symbolic link (for example, maybe I have
/usr/netscape/bin as a symlink to /usr/local/bin, but I want the
installation command to record the path name as /usr/netscape/bin).
>If one absolutely wants the command to use the exact form of the
>dependency that's used in the dependency list, it's easy to simply
>reproduce that form, replacing the % by $*
Sorry, I do not understand what you mean. If you want to
explain it to me, you may have to write the rule out.
Thanks for the better workaround and the advice.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."