make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Adam J. Richter]

	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
adam@yggdrasil.com     \ /                  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."

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit "Adam J. Richter" <adam@yggdrasil.com>

[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"

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Riley Williams]

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.

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Kai Germaschewski]

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

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Adam J. Richter]

enning Makholm wrote:
>Scripsit "Adam J. Richter" <adam@yggdrasil.com>
>> 	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
adam@yggdrasil.com     \ /                  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."

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Riley Williams]

Hi Kai.

>>>> $(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.

Providing it is always exactly equivalent, I have no problem with it.

To be honest, I have no real interest in this particular issue as the
Linux-Hams package is inherently Linux specific, GNU make is the only
version of make used with Linux (as far as I have seen anyway), and GNU
make (in all versions I have met) correctly expands $(...) as a single
token wherever it is met. The problem I was referring to only relates to
some of the non-GNU make's used - certainly, the early Solaris versions
were known to do just that. I haven't used Solaris since 1999 so don't
feel qualified to comment on recent versions.

> Anyway, $(obj) is just "." currently, so it doesn't have a space in it.

Is that fixed as such for ever?

If so, what is the purpose behind having the definition in the first place?

> 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.

For many packages I've worked on, OBJ is defined as $(SRC)/../obj so if
$(SRC) has a space in it, then $(OBJ) will as well. My preferred version
deals with the entire problem in a different way:

 1. Each subdirectory has a Makefile that begins with...

	BASEDIR=..
	include $(BASEDIR)/Makefile-rules

    ...where the definition of BASEDIR is the relative path from the
    current directory to the base of the source tree for that package.

 2. $(BASEDIR)/Makefile-rules contains the following...

	TOPDIR = $(shell cd $(BASEDIR) ; set -P ; pwd)
	INCDIR = $(BASEDIR)/include
	OBJDIR = $(BASEDIR)/obj

    ...after which TOPDIR is the canonical path to the root directory
    of the package's source, INCDIR is the relative path from the
    current directory to the package include files directory, and
    OBJDIR is the relative path from the current directory to the
    common object directory.

Given those definitions, one can guarantee that problems such as the
above do not occur simply by not using directory names with spaces in
them inside the tree, and it also has the advantage that the resulting
tree is not dependent on where it is placed in the user's system.

In addition, this method guarantees that the commands used to compile
*.c files into *.o files will be exactly the same throughout the source
tree, thus preventing bugs resulting from incompatible optimisations in
different source files. This guarantee arises because the command
sequence to use is only defined in the common $(BASEDIR)/Makefile-rules
file, and not separately in each individual Makefile.

> 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.

The above does all that is necessary.

> I also think the two are functionally equivalent even if $(obj)
> contains a space, but I haven't tried at all.

With all versions of GNU make that I have tried, they are identical but
with some of the other make's out there, they are not, and that is what
causes problems such as the above to surface.

My stance on this is quite simple: If I write a program that isn't
inherently Linux specific, I would prefer for it to work unmodified on
Solaris, AIX and just about any other version of UNIX that may be out
there, so it can just be dropped on a system and the user run something
like `make config install` and ends up with a system on which it works.
Oddities such as relying on GNU make being the version of make installed
on that system are very much unwelcome as a result.

Best wishes from Riley.

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit Riley Williams <rhw@InfraDead.Org>

> >> $(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"

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit Riley Williams <rhw@InfraDead.Org>

> Linux-Hams package is inherently Linux specific, GNU make is the only
> version of make used with Linux (as far as I have seen anyway), and GNU
> make (in all versions I have met) correctly expands $(...) as a single
> token wherever it is met.

No it doesn't. If it did, it idiomatic rules such as

binary: $(OBJS)
	$(CC) -o $< $(OBJS)

would not work.


It is even easy to check this:

pc-043:~/foo$ cat Makefile
foo = a b
bar:
        ./echonum $(foo) stop
pc-043:~/foo$ cat echonum
#! /bin/sh
while true ; do
  echo $1
  [ "$1" = stop ] && exit 0 ;
  shift
done
pc-043:~/foo$ gmake bar
./echonum a b stop
a
b
stop
pc-043:~/foo$ gmake --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-linux-gnu
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.

pc-043:~/foo$ 

-- 
Henning Makholm        "Hvorfor skulle jeg tale som en slave og en tåbe? Jeg
                ønsker ikke, at han skal leve evigt, og jeg ved, at han ikke
               kommer til at leve evigt, uanset om jeg ønsker det eller ej."
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit "Adam J. Richter" <adam@yggdrasil.com>

> >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."

[PATCH] Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Thomas Sailer]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Sat, 2002-06-22 at 08:57, Adam J. Richter wrote:
> 	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.

Thanks for investigating this, but I propose another fix, namely to
remove soundmodem altogether. Linus, please do:

rm -rf drivers/net/hamradio/soundmodem
and then apply the attached patch.

Why?
* There is a usermode only replacement now (and for several years
already), which works with most OSS interface sound drivers
* The kernel stuff is limited to a few ISA cards, and nowadays
mainboards with ISA slots almost ceased to exist, same with ISA
soundcards

Thanks

Tom


[-- Attachment #2: soundmodem_remove.diff --]
[-- Type: text/plain, Size: 6930 bytes --]

--- 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 \

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Paul D. Smith]

If your goal is to avoid GNU make-isms, you've got a long way to go.

Patterns are not portable.

Include is not portable.

Even use of $< in explicit rules is not portable.


If you want to write truly portable makefiles, none of the issues raised
in this post have any relevance to you, since you cannot use any of the
features which may be impacted by it in the first place.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist