Re: Some more msvc++ 8.2.4 build feedback

In addition to the encoding issues I have with the 8.2.4 MSVC++ build
(see previous email), there are some other issues that I've run into:

1. The custom build step that generates DEF files for DLLS using a perl
script does not work. The perl script runs, and a slew of symbol
information is output to the MSVC++ console. And a def file is created,
but it always empty.

If you run the perl script (gendef.pl) by hand from a DOS prompt, the
DEF file is created correctly. That of course is a bit of pain since
you have to do it for a number of the MSVC++ projects.

2. The build has hard-coded paths (as far as I can see) to zlib and
openssl. Is there a way to a) remove them or b) change them ahead of
time so you don't have to manually change 20+ project files?

3. If you have a contrib module that is not known to the build system
it blows up. For example, I use PostGIS. When running build.bat it
stops at postgis (sorry, I didn't write down the error message but can
easily get it if needed). Could unknown contrib modules just be skipped
instead?

4. I was surprised to find out that a MSVC++ build cannot open a
database cluster created by a MSYS build (not sure about vice versa
since I didn't checked). When running pg_ctl start a checksum error is
returned. Is this expected? I got around it by doing a dump from the
MSYS database and a restore into the MSVC++ database, which worked fine.

Hope these comments help - and thanks for providing the build scripts.
They make it *much* easier to debug postgresql and contrib modules on
Windows.

Out of curiosity, will the MSVC++ build become the default for 8.3 on
Windows or will it remain MSYS for a bit longer?

Thanks,

Charlie

Charlie Savage wrote:
>
> Out of curiosity, will the MSVC++ build become the default for 8.3 on
> Windows or will it remain MSYS for a bit longer?
>
>

There is no such thing as a default build.

As far as I am concerned we will support MSys into the indefinite future.

cheers

andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Dunstan wrote:
>
>
> Charlie Savage wrote:
>>
>> Out of curiosity, will the MSVC++ build become the default for 8.3 on
>> Windows or will it remain MSYS for a bit longer?
>>
>>
>
> There is no such thing as a default build.
>
> As far as I am concerned we will support MSys into the indefinite future.

My immediate guess is he is asking, "When I download the installer. What
build am I getting?". My "guess" is that with 8.3 it will be MSVC++.

Sincerely,

Joshua D. Drake

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

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG1jlNATb/zqfZUUQRAtfvAJ9/qou1k/Ftjk5ukgH1pxePfWC5dACgjgQO
o4N5lKCSZZSUyayyIQ4VSps=
=bZKx
-----END PGP SIGNATURE-----

Joshua D. Drake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Dunstan wrote:
>
>> Charlie Savage wrote:
>>
>>> Out of curiosity, will the MSVC++ build become the default for 8.3 on
>>> Windows or will it remain MSYS for a bit longer?
>>>
>>>
>>>
>> There is no such thing as a default build.
>>
>> As far as I am concerned we will support MSys into the indefinite future.
>>
>
> My immediate guess is he is asking, "When I download the installer. What
> build am I getting?". My "guess" is that with 8.3 it will be MSVC++.
>
>

That doesn't make it the default any more than the fact that Fedora's
package is built with gcc makes it a default. But I guess I see what you
mean.

cheers

andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Dunstan wrote:

>> My immediate guess is he is asking, "When I download the installer. What
>> build am I getting?". My "guess" is that with 8.3 it will be MSVC++.
>>
>>
>
> That doesn't make it the default any more than the fact that Fedora's
> package is built with gcc makes it a default. But I guess I see what you
> mean.

It makes it the default on windows, by default ;) because that is how
people are going to install it on windows.

Joshua D. Drake

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG1jwZATb/zqfZUUQRAol+AJ4ob+IUgz2bw9AxBelUtIefOoXmRgCfRyLZ
4WdEknvvHlLwuSwLVnEFgx0=
=vtiX
-----END PGP SIGNATURE-----

On Wed, Aug 29, 2007 at 08:53:55PM -0600, Charlie Savage wrote:
> In addition to the encoding issues I have with the 8.2.4 MSVC++ build
> (see previous email), there are some other issues that I've run into:
>
> 1. The custom build step that generates DEF files for DLLS using a perl
> script does not work. The perl script runs, and a slew of symbol
> information is output to the MSVC++ console. And a def file is created,
> but it always empty.
>
> If you run the perl script (gendef.pl) by hand from a DOS prompt, the
> DEF file is created correctly. That of course is a bit of pain since
> you have to do it for a number of the MSVC++ projects.

Yeah, this is a known problem, and it's fixed for 8.3. Really, the msvc
build process in 8.2 has a *lot* of rough edges ;-) The code itself builds
fine, but the buildsystem needed a lot more work.

> 2. The build has hard-coded paths (as far as I can see) to zlib and
> openssl. Is there a way to a) remove them or b) change them ahead of
> time so you don't have to manually change 20+ project files?

They are set in config.pl. Change it there and re-run the mkvcbuild script
and it'll update all those places.

> 3. If you have a contrib module that is not known to the build system
> it blows up. For example, I use PostGIS. When running build.bat it
> stops at postgis (sorry, I didn't write down the error message but can
> easily get it if needed). Could unknown contrib modules just be skipped
> instead?

Uh, can you explain more what you mean? How can the pg build be affected by
postgis?

> 4. I was surprised to find out that a MSVC++ build cannot open a
> database cluster created by a MSYS build (not sure about vice versa
> since I didn't checked). When running pg_ctl start a checksum error is
> returned. Is this expected? I got around it by doing a dump from the
> MSYS database and a restore into the MSVC++ database, which worked fine.

No, it's not really expected, that should work. Are they compiled with the
same options? Compare pg_controldata output between the two clusters (using
mingw pg_controldata for the mingw install and msvc dfor the msvc install
of course)

> Hope these comments help - and thanks for providing the build scripts.
> They make it *much* easier to debug postgresql and contrib modules on
> Windows.
>
> Out of curiosity, will the MSVC++ build become the default for 8.3 on
> Windows or will it remain MSYS for a bit longer?

The binary distribution will be using the MSVC++ build for 8.3. But we'll
keep msys around and fullyi supported, of course.

//Magnus

Hi Magnus,

> Yeah, this is a known problem, and it's fixed for 8.3. Really, the msvc
> build process in 8.2 has a *lot* of rough edges ;-) The code itself builds
> fine, but the buildsystem needed a lot more work.
>
Great - figured that might be the case.

>> 3. If you have a contrib module that is not known to the build system
>> it blows up. For example, I use PostGIS. When running build.bat it
>> stops at postgis (sorry, I didn't write down the error message but can
>> easily get it if needed). Could unknown contrib modules just be skipped
>> instead?
>>
>
> Uh, can you explain more what you mean? How can the pg build be affected by
> postgis?
>
Download postgis source and put it under contrib/postis. Then:

C:\Development\msys\src\postgresql-8.2.4\src\tools\msvc>perl mkvcbuild.pl
Could not determine contrib module type for postgis-1.2.1
at mkvcbuild.pl line 326
main::AddContrib('postgis-1.2.1') called at mkvcbuild.pl line 200

There is a loop in mkvcbuild.pl that processes the contrib modules:

my $D;
opendir($D, 'contrib') || croak "Could not opendir on contrib!\n";
while (my $d = readdir($D)) {
next if ($d =~ /^\./);
next unless (-f "contrib/$d/Makefile");
next if (grep {/^$d$/} @contrib_excludes);
AddContrib($d);
}
closedir($D);

Perhaps I shouldn't be installing the postgis source to contrib, but
that used to be the recommended practice (at least for PostGis).

Thanks for the help,

Charlie

Charlie Savage wrote:
> Hi Magnus,
>
>> Yeah, this is a known problem, and it's fixed for 8.3. Really, the msvc
>> build process in 8.2 has a *lot* of rough edges ;-) The code itself builds
>> fine, but the buildsystem needed a lot more work.
>>
> Great - figured that might be the case.
>
>>> 3. If you have a contrib module that is not known to the build system
>>> it blows up. For example, I use PostGIS. When running build.bat it
>>> stops at postgis (sorry, I didn't write down the error message but can
>>> easily get it if needed). Could unknown contrib modules just be skipped
>>> instead?
>>>
>>
>> Uh, can you explain more what you mean? How can the pg build be affected by
>> postgis?
>>
> Download postgis source and put it under contrib/postis. Then:
>
> C:\Development\msys\src\postgresql-8.2.4\src\tools\msvc>perl mkvcbuild.pl
> Could not determine contrib module type for postgis-1.2.1
> at mkvcbuild.pl line 326
> main::AddContrib('postgis-1.2.1') called at mkvcbuild.pl line 200
>
> There is a loop in mkvcbuild.pl that processes the contrib modules:
>
> my $D;
> opendir($D, 'contrib') || croak "Could not opendir on contrib!\n";
> while (my $d = readdir($D)) {
> next if ($d =~ /^\./);
> next unless (-f "contrib/$d/Makefile");
> next if (grep {/^$d$/} @contrib_excludes);
> AddContrib($d);
> }
> closedir($D);
>
>
> Perhaps I shouldn't be installing the postgis source to contrib, but
> that used to be the recommended practice (at least for PostGis).

Oh, didn't realise you'd stick it in the actual contrib tree. I thought
it would build with pgxs or something.

I'll put it on my TODO to change that code to look at the Makefile
instead of the directories. Unless you want to send in a patch :-P

//Magnus

> Oh, didn't realise you'd stick it in the actual contrib tree. I thought
> it would build with pgxs or something.

You used to have to build postgis from the contrib directory. That
changed a while back, but I guess its just habit. It has its own
configure and makefile scripts, so doesn't seem to use pgxs.

> I'll put it on my TODO to change that code to look at the Makefile
> instead of the directories. Unless you want to send in a patch :-P

Thanks. No patch from me - my perl and autoconf skills leave something
to be desired :)

Charlie