Gary V. Vaughan wrote:
> A make portability bug shows up on sgi:
> mips-sgi-irix6.5$ make all check
> make all-recursive
> Making all in .
> Making all in examples
> Making all in lib
> cp ../../lib/getopt_.h getopt.h-t
> mv getopt.h-t getopt.h
> sed -e 's/@''HAVE__BOOL''@/0/g' < ../../lib/stdbool_.h > stdbool.h-t
> mv stdbool.h-t stdbool.h
> make all-am
> cc -DHAVE_CONFIG_H -I. -I../../lib -I.. -g -c strnlen1.c
> cc ERROR: file does not exist: strnlen1.c
> *** Error code 2 (bu21)
> *** Error code 1 (bu21)
> *** Error code 1 (bu21)
> *** Error code 1 (bu21)
> mips-sgi-irix6.5$ gmake all check
> [[...]]
> All checks successful
You're attempting a VPATH build with a non-GNU make. This is not supported.
See the INSTALL file:
"You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you can use GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
With a non-GNU `make', it is safer to compile the package for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use `make distclean' before
reconfiguring for another architecture."
See also autoconf's documentation:
"If you use
@code{VPATH}, the simplest way to avoid these portability bugs is to
stick with @acronym{GNU} @command{make}, since it is the most
commonly-used @command{make} among Autoconf users."
Bruno
_______________________________________________
M4-discuss mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/m4-discuss
