Darren J Moffat <[EMAIL PROTECTED]> wrote: > > > Please give a full reference. > > > > POSIX. > > That isn't a full reference with version number, but it was enough > to get me started.
http://www.opengroup.org/onlinepubs/009695399/utilities/make.html > > Well in contraty to GNU make, Sun make includes a warning in the man > > page.... > > But as few people tend to read the man page, it is better to warn every time > > a dynamic macro is evaluated for an explicit rules as smake does. > > So you have logged a bug with Sun about this no complaint behaviour, > right ? > > With http://bugs.opensolaris.org/ you can do it yourself. It does not really make sense to file a bug against make because the bug sits inside the makefiles that depend on this behavior "bejond documentation". $< In an inference rule, the $< macro shall evaluate to the filename whose existence allowed the inference rule to be chosen for the target. In the .DEFAULT rule, the $< macro shall evaluate to the current target name. The meaning of the $< macro shall be otherwise unspecified. What we see here is "unspecified behavior" from the POSIX standard language. Sun make documents that this behavior is problematic but the fact that smake is the only make program that warns about the missusage and the fact that smake seems not to be well known, results in a lot of free software that just compiles because of good luck mostly only using GNU make. ... because the authors implement code that matches GNU make bugs. This makefile documents that the fact that Sun make expads $< at all is not a good idea because it will not do what people expect with a ~ 10% probability. > > touch test.o test.bla.xx test.c test.x > > > > test.o test.x > > test.o: test.bla.xx > > echo xifying $< > > xify -o $@ $< > > > > Now guess what Sun Make does > > Why do I have to guess, why can't you just tell us what the behaviour is > and what you believe POSIX requires it to be. > > Does /usr/xpg4/bin/make act the same way ? Jes, it does /usr/xpg4/bin/make echo xifying test.c xifying test.c xify -o test.o test.c sh: xify: nicht gefunden *** Error code 1 make: Fatal error: Command failed for target `test.o' Now look what smake does: smake smake: WARNING: requesting implicit dynmac '$<' for explicit target 'test.o' smake: WARNING: expanding implicit dynmac '$<' to '' smake: WARNING: Current working directory: '/tmp/TD', Makefile 'Makefile' ...echo xifying xifying smake: WARNING: requesting implicit dynmac '$<' for explicit target 'test.o' smake: WARNING: expanding implicit dynmac '$<' to '' smake: WARNING: Current working directory: '/tmp/TD', Makefile 'Makefile' ...xify -o test.o sh: xify: nicht gefunden smake: Not owner. *** Code 1 from command line for target 'test.o'. smake: Couldn't make 'test.o'. In our case, the explicit rule is written to transform test.bla.xx to test.o using the "compiler" xify. So the source suffix is ".bla.xx" and the target suffix is ".o". make cannot know about this and for this reason it is impossible to expand $< in this case. As a result of the fact that this kind of translataion does not work, Sun make cannot be used to compile samba and nonody knows why. GNU make uses a different aproach that fails with other constraints. As Sun make just fails with samba but does not write an error message or a warning, people believe that Sun make is broken because GNU make works. The aproach from my smake is to tell people that the defective makefile is the cause for the problem. This behavior gives a higher chance that the Samba (or other) authors fix their broken makefiles. Note that the main reason for compilation problems on Solaris using Sun make is this kind of buggy makefiles. It seems that the advantage of smake is that every time I see a problem that took me too long to find, I try to enhance the smake parser to give better warnings and as a result, it usually now takes me less than 5 minutes to identify broken makefiles from free software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
