Bruce Momjian wrote:

Andrew Dunstan wrote:


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.





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.



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

Reply via email to