Bruce Momjian wrote:
Andrew Dunstan wrote:
Even if we don't do that can we *please* put in something that detects the error, and tells the user what they will have to do to fix it? Failing in a situation which we know we can detect and not telling the user is intolerable, IMNSHO.It's different because we know why we need that one: we understand the cause of the behavior and we therefore can have some confidence that the kluge will fix it (or not, as the case may be). I have zero confidence in looping five times around an "ln" call.
Agreed. At a minium we have to throw an error and tell them to run it
again.
This patch for configure.in detects the link failures in MINGW that I and others have seen and warns the user they have to fix it up.
cheers
andrew
Index: configure.in =================================================================== RCS file: /projects/cvsroot/pgsql-server/configure.in,v retrieving revision 1.345 diff -c -r1.345 configure.in *** configure.in 7 May 2004 00:24:57 -0000 1.345 --- configure.in 8 May 2004 15:47:01 -0000 *************** *** 1237,1242 **** --- 1237,1260 ---- src/Makefile.port:src/makefiles/Makefile.${template} ]) + # Links sometimes fail undetected on Mingw - + # so here we detect it and warn the user + case $host_os in mingw*) + AC_OUTPUT_COMMANDS([ + for linktarget in \ + src/backend/port/tas.s \ + src/backend/port/dynloader.c \ + src/backend/port/pg_sema.c \ + src/backend/port/pg_shmem.c \ + src/include/dynloader.h \ + src/include/pg_config_os.h \ + src/Makefile.port ; do + test -e $linktarget || echo " ***" link for $linktarget failed - please fix by hand + done + ]) + ;; + esac + AC_CONFIG_HEADERS([src/include/pg_config.h], [ # Update timestamp for pg_config.h (see Makefile.global)
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings