[gdal-dev] vsicurl access to a netcdf file does not see the coordinates

[Joaquim Manuel Freire Luís]

|>> Rebuilding my HDF+netCDF+GDAL stack, but now when issue the final
|>>
|>> nmake /f makefile.vc devinstall
|>
|>Ah, there is no chance that /vsicurl/ with netcdf will work on Windows. It also
|>requires the "user-fault file descriptor" Linux specific mechanism.

Ah, I had the impression that recent improvements on this had made it possible to use on Windows as well.

Regarding the docs build. Yes, it absolutely must be decoupled  to a different target. I happen to have Mingw also available from within the command shell env that use to build with VS, and after all the updates that it obliged me to do my Python environment, I finally managed to do the devinstall. But not without a little patch. At the end it still errored complaining that ../latex/gdal.pdf  did not exists (and it was right). I worked around it by commenting that line in the Makefile

Still other issues. 

1- I build both 32 & 64 bit versions but now the nmake clean does not remove all the .obj files, so after building for 64 bits, the 32 bits fails due to x86 vs x64 conflicts.

2- This proj (but you also ware that hat). Proj 6 creates include libs that have the version number (e.g. proj_6_0.lib, proj_6_1.lib, ...). That is not very nice. I declare in my nmake.local

PROJ_LIBRARY = C:\programs\compa_libs\proj5_GIT\compileds\$(LIB_CC)\lib\proj_6_0.lib

And I still had that lib in place so it linked fine to GDAL, but on runtime I started having missing symbols errors (in this case proj_coordoperation_get_method_info) that took me a while to fire out that the problem as that lib name must be updated to

PROJ_LIBRARY = C:\programs\compa_libs\proj5_GIT\compileds\$(LIB_CC)\lib\proj_6_1.lib

GDAL uses only the version independent "gdal_i.lib". Why isn't proj doing the same thing? As is, it's very easy to fall in this trap.


(Hmm, damn it, finished rebuilding GDAL and still have that proj_coordoperation_get_method_info missing error)

|>> it errors after a while with (complains about doxygen). This didn't
|>> use to happen. I have a Win doxygen but it's not (never been) in the path.
|>>
|>> make: Entering directory '/c/programs/compa_libs/gdal_GIT/gdal/doc'
|>> mkdir -p build/xml && cd .. && ((cat Doxyfile | sed "s/PREDEFINED
|>>  = /PREDEFINED             = DOXYGEN_XML /"; printf
|>>
|>"GENERATE_HTML=NO\nGENERATE_XML=YES\nXML_OUTPUT=doc/build/xml\
|>nXML_PRO
|>> GRAML
|>> ISTING=NO") | doxygen -) /bin/sh: doxygen: command not found
|>> make: *** [Makefile:22: .doxygen_up_to_date] Error 127
|>> make: Leaving directory '/c/programs/compa_libs/gdal_GIT/gdal/doc'
|>> NMAKE : fatal error U1077: 'C:\MinGW64\msys64\usr\bin\make.EXE' :
|>> return code '0x2' Stop.
|>
|>I see Jürgen had to made changes in makefile.vc due to the documentation/
|>website refactoring, and now there is:
|>
|># build using cygwin
|>docs:
|>        make PYTHONHOME= -C doc html
|>
|>install: default docs
|>
|>Jürgen, we probably don't want to require cygwin for the install & devinstall
|>targets. I would rather see doc building as an explicit separate target - that is
|>not a dependency of install - and if it has been run explicitly before install, then
|>we can install the docs, and otherwise just ignore them. What do you think ?
|>
|>I've filed https://github.com/OSGeo/gdal/issues/1608 about that.
|>
|>Even
|>
|>--
|>Spatialys - Geospatial professional services http://www.spatialys.com