Re: New Software License idea: "The Freedom License."

[Karen Hill]

Alfred M. Szmidt wrote:
> -     Backshlash handling is completely broken in the gmake makefile parser.
>          GNU make is trying to work around the problems caused by the
>          proken parser by adding dozens of #ifdef WIN32 constructs.
>
>          A parser that follows the POSIX standard does not need a single
>          line od DOS/Win32 specific code.
>
> Concrete example?
>
>    -  Space handling (e.g. escaped newlines) is completely broken in
>          the gmake makefile parser.
>
>          Use this Makefile:
>    FOO=a\
>    \
>    \
>    \
>    b
>
>    all:
>          @echo "${FOO}"
>
>          Test with Sun make, smake (ftp://ftp.berlios.de/pub/smake/alpha/)
>          and gmake:
>
>          \make
>          a    b
>          smake
>          a    b
>          gmake
>          a b
>
> Care to quote line and verse of POSIX?  I couldn't find where this
> must be the behaviour of a POSIX compliant make.  Infact, this is what
> IEEE Std 1003.1-2004 (the only thing I had in my posession at this
> time, but it should be good enough) says:


WRONG!  You must follow the standard to a tee if you want to be
compliant.  Otherwise you are extending, just like Microsoft does.
Remember what MS did to its version of the JVM?  That's right they
added Microsoft extentions to the JVM and when app writers used those
extensions, they were not portable to other OSes.  Would you call
Microsoft's "Managed C++" standard C++?  I would not because it follows
and then extends the ISO C++ standards as to work with the .NET
framework.

Another way to think of this is why not include a LISP interpreter in
gmake?  It would be a "feature" in your world.


> f= bar baz\
>    biz
> a:
>       echo ==$f==
>
>          echoes "==bar baz biz=="
>
> >From the looks, smake and whatever `make' is supposed to be are not
> following the relevant standards, while GNU Make is.  Maybe you are
> refering to something else?  Quote? URL?
>
>    -  GNU make incorrectly expands "$<" for non-inplicit rules.
>          It is impossible to expand "$<" to something useful in
>          explicit rules.
>
> Concrete example?
>
>          The fact that GNU make expands it to something strange
>          causes many people to write broken Makefiles that depend
>          on the GNU make bugs.
>
> What you consider a bug, people consider a feature.  Can you show
> where POSIX prohibits this behaviour?
>
>    -  GNU make incorrectly expands "$*" for non-inplicit rules.
>          It is impossible to expand "$*" to something useful in
>          explicit rules.
>
> Concrete example?
>
>          The fact that GNU make expands it to something strange
>          causes many people to write broken Makefiles that depend
>          on the GNU make bugs.
>
> What you consider a bug, people consider a feature.  Can you show
> where POSIX prohibits this behaviour?

Joerg won't see your post as he reads only comp.unix.solaris.  He knows
all about the MAKE POSIX standard because he wrote his own MAKE program
called "smake"!!!   smake is POSIX compliant unlike gmake.

"What you consider a bug, people consider a feature" is a frequent
Microsoft utterance.  When people use  GNU makes "bug"  they prevent
portability to other platforms as Joerg mentioned in another message.