SVN version won't build on Windows

[jluis]

It errors with

[ 81%] Building CXX object capi/CMakeFiles/geos_c.dir/geos_c.cpp.obj
geos_c.cpp
V:\geos_SVN\build\capi\geos_c.h(826) : error C2059: syntax error : '__declspec(dllexport)'
V:\geos_SVN\build\capi\geos_c.h(831) : error C2059: syntax error : '__declspec(dllexport)'
V:\geos_SVN\build\capi\geos_c.h(1746) : error C2059: syntax error : '__declspec(dllexport)'
V:\geos_SVN\build\capi\geos_c.h(1764) : error C2059: syntax error : '__declspec(dllexport)'
V:\geos_SVN\capi\geos_c.cpp(1165) : error C3861: 'GEOSSTRtree_nearest_generic': identifier not found
V:\geos_SVN\capi\geos_c.cpp(1174) : error C3861: 'GEOSSTRtree_nearest_generic_r': identifier not found
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe' : return code '0x2'

[strk]

Probably a missing file in the vc build scripts, but nobody likes windows so nobody cares to maintain those scripts. If you send a patch, it could be applied.

[alant]

This error applies to both cmake and nmake builds with visual studio 2015.

[strk]

That's a feature ! People should be discouraged from running proprietary systems :)

[jluis]

Replying to strk:

That's a feature ! People should be discouraged from running proprietary systems :)

Please, I also do many open source contributions and had enough of that talk. :)

[mloskot]

Fixed in trunk (r4209).

Fixed CMake configuration in branches/3.5 (r4210) and trunk (r4211).

[alant]

Thanks for the quick response, which has cleared most of the problems.

However I am still seeing these two:

2>c:\xxx\capi\geos_c.h(1746): error C2059: syntax error: 'declspec(dllexport)' (compiling source file C:\xxx\libgeosGit\capi\geos_ts_c.cpp)

2>c:\xxx\libgeosgit\capi\geos_c.h(1764): error C2059: syntax error: 'declspec(dllexport)' (compiling source file C:\xxx\libgeosGit\capi\geos_ts_c.cpp)

Alan

[mloskot]

I have just double checked building the trunk with VS2015 (configured with CMake, loading GEOS.sln into VS) and all builds fine.

You really need to be more specific

• what compiler
• how you configure
• what is geos_c.h(1746)
• what branch, what revision, what is geos_c.h(1746) line in your working copy.

The line geos_c.h(1746) looks fine in the current trunk:

extern const GEOSGeometry GEOS_DLL *GEOSSTRtree_nearest(GEOSSTRtree *tree, const GEOSGeometry* geom);

[alant]

It is afer midnight here and I have just acheived a clean build.

I have finally found that the problem is related to the capi/geos_c.h generation from geos.c.h.in.

At first sight it seems that if geos.c.h exists then the update is not performed - in other words your git update is ignored. I need to confirm this with some tests.

The clean build came after I used git to remove all unversioned files and then started with cmake again and got a successful build (after making geos_svn_revision.h by hand)

I am using the current version of MSVC 2015 and cmake 3.6.0 on my desktop computer and cmake 3.2.2 on my laptop. They behave differently when failing to update geos_svn_revision.h.

MSVC 2015 version numbers change regularly as Microsoft throws automatic updates out of the door, so nmake.opt is always out of date.

So the code is good, but cmake is having problems.

Thank you for your patience.

Alan

[mloskot]

geos_c.h should now be generated inside build folder, for example, build\capi\geos_c.h, but not inside capi sources folder.

The file geos_c.h should be regenerated every time geos_c.h.in is modified, according to ​CMake configure_file:

If the input file is modified the build system will re-run CMake to re-configure the file and generate the build system again.

If you build with CMake, you should not need to create geos_svn_revision.h by hand. It is now generated automatically. I'm using CMake 3.5.1 and it works well here. So, I haven't observed any problems with CMake so far.

Regarding VS and NMAKE version numbers hard-coded in NMAKe makefiles, it is known trade-off and we try to keep the list up to date, but often with delay.

[alant]

Last night I cleared the compilation on my laptop. Today I cleared the compilation on my desktop machine by the same method .

After that I replaced the geoc.c.h file in the root /capi folder, next to the geoc.c.h.in file, but was unable to replicate the compilation fault. (Note I do my cmake builds out-of-source)

All I suggest is that windows compilation faults may be cleared by doing a complete clean download into an empty directory.

Thanks for your assistance.

Alan