K. Richard Pixley wrote: > I notice that automake is currently generating Makefiles that violate > the gnu coding conventions.
Hmm... I don't think that automake violates the standards. In the normal case it is not required to have automake installed. Someone who is simply building from the generated Makefiles never needs to have automake installed. Only a developer who is modifying the automake source files would need automake installed. Obviously from the questions you are asking you are experiencing a specific problem. Could you share some details? I would rather see the problems you are experiencing addressed rather than see the generated Makefiles crippled. There is always AM_MAINTAINER_MODE but I think the cure is many times worse than the disease. Meanwhile, let me address some of your points. > Specifically, it's generating rules for rebuilding "Makefile" from > "Makefile.in" and "Makefile.in" from "Makefile.am" which requires > automake. Rebuilding the generated Makefile.in file is only needed if the source file is modified. I don't see a good alternative in that case. If the automake source file is modified then presumably the person doing the modification wants the change and then automake would be required. Anyone doing this would fall into the developer role and there is an expectation that developers must have the appropriate tools available. If you are not modifying the automake source files then automake is not required. > Also, in the past, there were coding standards that prohibited Makefiles > from writing into $(srcdir). The problem here is that source code > directories might be read-only as comes from a cdrom, or from a shared > but not owned source directory, (perhaps on a network server). Please use VPATH builds for read-only source directories. Example: mkdir /tmp/project cd /tmp/project /media/cdrom/project/configure That is an example build from a read-only source directory. Note that 'make dist-check' simulates read-only source and is one check that projects can build from a read-only source tree. > Note that these problems are particularly troublesome when one uses a > file transfer method for copying or moving source trees that doesn't > necessarily retain last modification time stamps, like source code > control systems, "cp", etc. In these cases, the source directory > becomes unbuildable. When filestamps are munged then the simple action of touching all files to the same timestamp is a good workaround. find . -type f -print0 | xargs -r0 touch -r configure.ac Normally I would avoid munging timestamps of files. However in the case that they are already munged then I see no additional problem with getting them all into a consistent state. Again, I would appreciate it if you would describe the problem that you are experiencing that has led you here with a complaint about automake. Bob
