Fix for MSVC header installation

On Wed, Apr 25, 2007 at 02:57:41PM +0100, Dave Page wrote:

The MSVC installer doesn't install the headers in the same directory
structure as the Mingw build. This causes other apps (such as Slony) to
fail their configure tests.

The attached patch fixes this.

Applied, thanks.

FWIW, I mimicked the install layout on my Linux box. But we should
definitly be consistent with mingw instead :-)

//Magnus

Magnus Hagander wrote:

On Wed, Apr 25, 2007 at 02:57:41PM +0100, Dave Page wrote:

The MSVC installer doesn't install the headers in the same directory
structure as the Mingw build. This causes other apps (such as Slony) to
fail their configure tests.

The attached patch fixes this.

Applied, thanks.

FWIW, I mimicked the install layout on my Linux box. But we should
definitly be consistent with mingw instead :-)

Hmm, wonder why they are different? Especially as 8.2.4 on
developer.pgadmin.org (Slackware 11) seems to have the same layout as mingw!

Regards, Dave.

Dave Page wrote:

Magnus Hagander wrote:

On Wed, Apr 25, 2007 at 02:57:41PM +0100, Dave Page wrote:

The MSVC installer doesn't install the headers in the same directory
structure as the Mingw build. This causes other apps (such as Slony)
to fail their configure tests.

The attached patch fixes this.

Applied, thanks.

FWIW, I mimicked the install layout on my Linux box. But we should
definitly be consistent with mingw instead :-)

Hmm, wonder why they are different? Especially as 8.2.4 on
developer.pgadmin.org (Slackware 11) seems to have the same layout as
mingw!

pg_config IYF.

try: pg_config | grep INCLUDE

cheers

andrew

Andrew Dunstan wrote:

Dave Page wrote:

Magnus Hagander wrote:

On Wed, Apr 25, 2007 at 02:57:41PM +0100, Dave Page wrote:

The MSVC installer doesn't install the headers in the same directory
structure as the Mingw build. This causes other apps (such as Slony)
to fail their configure tests.

The attached patch fixes this.

Applied, thanks.

FWIW, I mimicked the install layout on my Linux box. But we should
definitly be consistent with mingw instead :-)

Hmm, wonder why they are different? Especially as 8.2.4 on
developer.pgadmin.org (Slackware 11) seems to have the same layout as
mingw!

pg_config IYF.

try: pg_config | grep INCLUDE

Right, but some of the directories that were in the wrong place were not
ones that could be located in the pg_config output - for example,
$INCLUDEDIR/internal was under $INCLUDEDIR/postgresql/internal.

And we really should make VC++ install in the same locations as mingw by
default anyway.

Regards, Dave.

Dave Page <dpage@postgresql.org> writes:

And we really should make VC++ install in the same locations as mingw by
default anyway.

I think you guys may be misinterpreting what's happening: this behavior
is not platform-sensitive, it is path-sensitive. In particular, the
configure script will interpolate /postgresql into some of the
installation paths unless the given path already contains "postgres"
or "pgsql". On some of my machines I build working versions into
/home/postgres, and there I get paths like
/home/postgres/version82/share/timezone/...
and on others I build into /home/tgl and get paths like
/home/tgl/version82/share/postgresql/timezone/...

So what I think is happening is that Magnus is getting fooled by which
username he builds under. The thing to standardize on is the full
path you want the stuff to install in (and make sure it doesn't mention
postgres twice).

regards, tom lane

Tom Lane wrote:

Dave Page <dpage@postgresql.org> writes:

And we really should make VC++ install in the same locations as mingw by
default anyway.

I think you guys may be misinterpreting what's happening: this behavior
is not platform-sensitive, it is path-sensitive. In particular, the
configure script will interpolate /postgresql into some of the
installation paths unless the given path already contains "postgres"
or "pgsql". On some of my machines I build working versions into
/home/postgres, and there I get paths like
/home/postgres/version82/share/timezone/...
and on others I build into /home/tgl and get paths like
/home/tgl/version82/share/postgresql/timezone/...

So what I think is happening is that Magnus is getting fooled by which
username he builds under. The thing to standardize on is the full
path you want the stuff to install in (and make sure it doesn't mention
postgres twice).

Yup. I had no idea it did that :-) It certainly explains the difference.
Since the default path is /usr/local/pgsql.. But on the linux box in
question I build into /home/mha/pginst/HEAD/.

//Magnus

------- Original Message -------
From: Magnus Hagander <magnus@hagander.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Sent: 25/04/07, 22:31:20
Subject: Re: [PATCHES] Fix for MSVC header installation

Yup. I had no idea it did that :-) It certainly explains the difference.

No, nor I, but it makes sense if you consider an install into /usr/local vs. /usr/local/pgsql for example.

Since the default path is /usr/local/pgsql.. But on the linux box in
question I build into /home/mha/pginst/HEAD/.

Hmm, that presents a possible problem as I can't see any way to restructure the layout based on the selected installation path in pgInstaller :-(. We should probably stick with the postgresql-already-in-the-path layout - no-one's ever complained, and that'll be the smallest issue for anyone porting code to win32.

Fixing the perl code shouldn't be an issue of course.

/D