"David A. Wheeler" <dwhee...@dwheeler.com> wrote: > > That as introduced by accident, because I did not realize at that time that > > gmake used an icompatible implementation that differs from smake and BSD > > make. > > That?s an unfortunate bug but easily fixed. It *is* specifically noted in the > Rationale :-).
Really? How do you like to fix that incompatible gmake behavior? > A person named ?joerg? in this bug report noted this semantic difference in > 2011-11-17 in our discussion on this topic: > https://www.austingroupbugs.net/view.php?id=330 > <https://www.austingroupbugs.net/view.php?id=330> > I take it you?re not the same person? Or maybe you knew this at one time & > forgot it later? > If you forgot it later, no big deal, forgetting happens to all of us :-). Please carefully read the SunPro Make man page: http://schilytools.sourceforge.net/man/man1/make.1s.html and try to understand what SunPro Make implemented for := in January 1986 - long before gmake existed. Maybe you understand your current misconception in depth. You already admitted your misconception and this is a good starter :-) Hint: the explanation is currently on page 17 and page 31. > >> The article "Recursive Make Considered Harmful" by Peter Miller > >> (http://miller.emu.id.au/pmiller/books/rmch/ [^] and > > > > This is an article from a person that does not know make(1) in depth (in > > special not the features from SunPro Make). The problems mentioned there are > > all solved by autoatic dependency handling via .KEEP_STATE: from SunPro > > Make > > (introduced in January 1986) and the automatic library dependency handling > > from SunPro Make via .KEEP_STATE: since approx. 1992. > > Peter Miller (who has deceased) was quite expert in make, specifically GNU > make: > https://accu.org/journals/overload/14/71/miller_2004/ > <https://accu.org/journals/overload/14/71/miller_2004/> > I realize you (Joerg) are partial to SunPro make, but many people are *never* > going to use > SunPro make and simply don?t care about it. > GNU Make is required for building many software systems, > including GCC (since version 3.4), the Linux kernel, LibreOffice, and Mozilla > Firefox. > For many people, ?make? *is* ?GNU make?. That does not change the fact that the claims in https://accu.org/journals/overload/14/71/miller_2004/ have been outdated long before that text was written, since the problems have been identified and fixed before - see .KEEP_STATE: > The *reason* that ?GNU make? is ?make? to many people is > partly because GNU make is a good implementation, and that?s fine. > However, it?s also because *practical* use of make often requires features > that are > not standardized in POSIX. The POSIX standard for make is dreadfully > impoverished today. > Adding at least one *standard* way to implement immediate execution is a step > towards > having a more powerful *standard* for make. That not only helps portability, > but it also encourages use of these more powerful mechanisms (*because* they > are standardized). The reason for that problem is the fact that gmake is incompatible to other make implementations and that caused problems in finding ways to get to a common way. I am trying to get POSIX make to be extenxed since a really long time in order to finally include the minimum set of common features needed for a portable makefile method. We currently still miss implicit pattern rules in POSIX and I really hope that we find a way to standardize at least the minimum subset for ISSUE 8 that would permit portable makefiles. BTW: gmake is the only make implementation that implements the minimum feature set needed for modern portable makefiles that at the same time is a constant source of problems caused by bugs. If you are in a bubble that only knows gmake, you may arrange yourself with these bugs, but if you intend to permit your users to use any make implementation, gmake is not part of the solution because gmake still does not care about compatibility. What I like to see in POSIX is a make definition that combines usability and interchangeability. The reason for the success of UNIX was that people did look at other implementations and reimplemented good ideas from other implementations by at the same time avoiding clashes and incompatiblities. If that was true for gmake as well, this was a big win for the future. Jörg -- EMail:jo...@schily.net Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
