|>> 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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
