Re: [pgsql-patches] [PATCHES] pg_regress updates for vc++ bulid

2007-01-19 Thread Magnus Hagander
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> A modified version of this was applied by Alvaro.
> 
> But note that the patch I applied was only the part of this that was not
> Windows-specific.  The rest is still needed to be able to use VC++
> builds as buildfarm members.  I'm not in a position to build that
> however, but it should be considerably thinner than what was in the
> queue.
> 
Right. Thanks for what you did apply. I will pull that one from cvs and
send an updated patch with just the win32 stuff.

//Magnus


---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [pgsql-patches] [PATCHES] pg_regress updates for vc++ bulid

2007-01-19 Thread Alvaro Herrera
Bruce Momjian wrote:
> 
> A modified version of this was applied by Alvaro.

But note that the patch I applied was only the part of this that was not
Windows-specific.  The rest is still needed to be able to use VC++
builds as buildfarm members.  I'm not in a position to build that
however, but it should be considerably thinner than what was in the
queue.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [pgsql-patches] [PATCHES] pg_regress updates for vc++ bulid

2007-01-19 Thread Bruce Momjian

A modified version of this was applied by Alvaro.

---

Magnus Hagander wrote:
> Magnus Hagander wrote:
> > Hello!
> > 
> > Per some previous discussion that I can't really recall if it was on or
> > off list, here is a WIP patch to make pg_regress run completely outside
> > of msys on win32.
> > 
> > The change needed is that the processing of files from input/ and
> > output/ into sql/ and expected/ is moved from the Makefile and into
> > pg_regress itself.
> > 
> > I have tested on Win32 non-MSVC and on Linux (non-VPATH), and it appears
> > to work there.
> > 
> > Still to be done is the "make install" part on MSVC build, currently
> > #ifdef:ed out. While working on that, I'd appreciate some comments on
> > the patch in general - if there are more things I need to fix before it
> > can be considered. Particularly I'm concerned around the VPATH stuff,
> > since I've never used that myself.
> 
> 
> Here's the patch without the WIP tag. It works for me per above, and
> also for a "check" (not just "installcheck") on msvc built without msys.
> 
> Again, the vpath part is the one I'm most unsure about, but I'm sure
> there could be other parts.
> 
> Hopefully this will make it possible to get the msvc build up on the
> buildfarm not too long from now.
> 
> Also, as in the first patch but not noted, this one makes it possible to
> run the regression tests as an admin account "the proper way" on both
> mingw and msvc.
> 
> //Magnus

> Index: src/include/port.h
> ===
> RCS file: c:/prog/cvsrepo/pgsql/pgsql/src/include/port.h,v
> retrieving revision 1.107
> diff -c -r1.107 port.h
> *** src/include/port.h5 Jan 2007 22:19:50 -   1.107
> --- src/include/port.h7 Jan 2007 15:11:12 -
> ***
> *** 46,51 
> --- 46,56 
>   extern bool get_home_path(char *ret_path);
>   extern void get_parent_directory(char *path);
>   
> + 
> + /* port/dirmod.c */
> + extern char **pgfnames(char *path);
> + extern void pgfnames_cleanup(char **filenames);
> + 
>   /*
>*  is_absolute_path
>*
> Index: src/port/dirmod.c
> ===
> RCS file: c:/prog/cvsrepo/pgsql/pgsql/src/port/dirmod.c,v
> retrieving revision 1.46
> diff -c -r1.46 dirmod.c
> *** src/port/dirmod.c 5 Jan 2007 22:20:02 -   1.46
> --- src/port/dirmod.c 7 Jan 2007 15:13:27 -
> ***
> *** 287,298 
>   
>   
>   /*
> !  * fnames
>*
>* return a list of the names of objects in the argument directory
>*/
> ! static char **
> ! fnames(char *path)
>   {
>   DIR*dir;
>   struct dirent *file;
> --- 287,298 
>   
>   
>   /*
> !  * pgfnames
>*
>* return a list of the names of objects in the argument directory
>*/
> ! char **
> ! pgfnames(char *path)
>   {
>   DIR*dir;
>   struct dirent *file;
> ***
> *** 357,368 
>   
>   
>   /*
> !  *  fnames_cleanup
>*
>*  deallocate memory used for filenames
>*/
> ! static void
> ! fnames_cleanup(char **filenames)
>   {
>   char  **fn;
>   
> --- 357,368 
>   
>   
>   /*
> !  *  pgfnames_cleanup
>*
>*  deallocate memory used for filenames
>*/
> ! void
> ! pgfnames_cleanup(char **filenames)
>   {
>   char  **fn;
>   
> ***
> *** 394,400 
>* we copy all the names out of the directory before we start modifying
>* it.
>*/
> ! filenames = fnames(path);
>   
>   if (filenames == NULL)
>   return false;
> --- 394,400 
>* we copy all the names out of the directory before we start modifying
>* it.
>*/
> ! filenames = pgfnames(path);
>   
>   if (filenames == NULL)
>   return false;
> ***
> *** 415,421 
>   if (!rmtree(filepath, true))
>   {
>   /* we already reported the error */
> ! fnames_cleanup(filenames);
>   return false;
>   }
>   }
> --- 415,421 
>   if (!rmtree(filepath, true))
>   {
>   /* we already reported the error */
> ! pgfnames_cleanup(filenames);
>   return false;
>   }
>   }
> ***
> *** 433,439 
>   goto report_and_fail;
>   }
>   
> ! fnames_cleanup(filenames);
>   return true;
>   
>   report_and_fail:
> --- 433,439 
>   goto report_and_fail;
>   }
>   
> ! pgfnames_cleanup(filenames);
>   return true;
>   
>   report_and_fail:
> ***
> *** 444,449 
>   fprintf(stderr, _("could not remove file or d