Re: [HACKERS] Some more msvc++ 8.2.4 build feedback
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
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Some more msvc++ 8.2.4 build feedback
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Some more msvc++ 8.2.4 build feedback
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
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [HACKERS] Some more msvc++ 8.2.4 build feedback
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Some more msvc++ 8.2.4 build feedback
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Some more msvc++ 8.2.4 build feedback
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
