[postgis-devel] Compilation using Visual C++ 8.0

[Mark Cave-Ayland]

Mateusz Loskot wrote:

>> - The patch includes a postgis/postgis.def file - should this not be 
>> generated as part of the compilation process rather than included as 
>> a static file in SVN?
> 
> It should not. postgis.def reflects state of postgis.sql.in.c
> in terms of list of currently available functions.
> Unfortunately, it has to be hacked manually. It's sort of part of
> so called DLL hell.

Ah okay. I'm fairly sure that PostgreSQL has some perl scripts that will 
generate this automatically, but probably Magnus will know better.

>> - The patch simply includes postgis.sql, rather than generating it 
>> from the C pre-processor. IMHO this one of the most important parts 
>> of the build system to get right for a given platform. How can this 
>> be emulated using MSVC?
> 
> I'm not sure what's the list of steps taken to generate it.
> Are there any Unix or autotools specific operations?
> I suppose it's just C/C++ preprocessor involved, isn't it?

Correct. It should be possible to invoke the preprocessor directly from 
the command line if required.

>> - I don't see any evidence of building liblwgeom into a static 
>> library. This is needed because not only does the library link with 
>> postgis-1.4.dll, but also with the shapefile loaders. I think this is
>>  also a critical part of the build to get right.
> 
> See liblwgeom.vcproj which produces liblwgeom.lib

Okay, now I see - sorry I must have skimmed this when I read the patch. 
So I can see that liblwgeom is now built from source, but I still can't 
see invocation of the parser utilities such as flex/bison to generate 
lex.yy.c/wktparse.tab.c from source.

>> Also I'd like to see evidence of a clean regression run from an MSVC 
>> build before committing some of this into the repository - just 
>> because it builds doesn't necessarily mean that it works ;)
> 
> You are right. I've run some of tests I selected randomly,
> i.e. regress.sql but I have not run full regress package.
> 
> Just to make things clear, I've prepared the build using Visual C++
> as a proof of concept, to show that there is no rocket science
> necessary to make it working, without using MinGW.
> However, I'm not going to pursue to submit it to the official
> PostGIS tree. I'm also not going to become maintainer of this
> configuration. I'm only going to update it if I have a free
> gap in my time or if I need it working myself.

Then unfortunately I think this project is probably dead :(  Since the 
new build system has been overhauled, I've pointed out several times 
that an MSVC build should now be relatively easy to do, it just needs 
someone to support it because the MS build tools live in their own 
little universe away from everyone else. I think that the work you've 
done here is great, but it comes back to the core issue that no one is 
willing to step up and maintain the MSVC build.

 From a personal perspective, I'm happy with MingW because the existing 
build system just works whether it's on Windows or Linux. I can get 
backtraces if required with gdb, and if I want a debug GUI then I can 
always stretch to Eclipse/CDT. There is just no way we can justify 
forcing developers to maintain parts of the MSVC builds which most of 
them can't even test just for the sake of one platform.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063