Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Win32 Version numbering patch

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Win32 Version numbering patch
Date: 2004-09-29 15:19:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
> > I was hoping this would be in for beta 3, but alas - can someone
> > *please* commit the win32 version patch at:
> >
> Personally I was holding off in hopes of seeing a cleaner solution.
> A patch that requires every executable-building Makefile to 
> have a platform-specific wart isn't going to be very 
> maintainable.  You already missed pg_config, plus whichever 
> of the contrib modules build executables...

IIRC, when this patch was posted, pg_config was a shellscript. Definitly
when the original version of the patch was posted. But sure, I should
probably have updated it when that changed.

Do you have any ideas on *how* to do this? Or specifically which parts
you don't like (or is it the whole concept)?  I had no idea you were
holding off based on that. I've asked repeatedly for comments about what
is bad, and this is the first time I heard something about the new patch
(other than the location of the files and the inclusion of the icon
which Peter E commented on sevearal times), if I'm not mistaken. 

Part of the versioninfo struct is file-specific, part is product
specific. I see no way around it other than having some parts of it in
every Makefile. Sure, we could have some kind of central mapping file
somewhere, but I would consider that *less* maintainable.

I specifically did not include contrib modules. That can be done once we
have a final verdict on exactly how it should be.


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-09-29 15:27:42
Subject: Re: shared memory release following failed lock acquirement.
Previous:From: Oleg BartunovDate: 2004-09-29 15:08:03
Subject: Re: tsearch2 poor performance

pgsql-patches by date

Next:From: Tom LaneDate: 2004-09-29 15:34:31
Subject: Re: new target for contrib/Makefile
Previous:From: Andrew DunstanDate: 2004-09-29 14:54:03
Subject: new target for contrib/Makefile

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group