[gdal-dev] GDAL conda build

Wed Nov 11 05:35:54 PST 2020

The documents are horrendously out of date - I know :)

I am assuming that you have seen this and that it does not meet your reqs
https://gdal.org/drivers/vector/openfilegdb.html#vector-openfilegdb

Building with an additional driver could, I guess, easily make a difference.

I am wondering if you have tried a vanilla build first - to see if it is
all working

Personally - I would do this :

- Clone the gdal-feedstock repo onto my local machine
- cd gdal-feedstock                           // cd into the gdal-feedstock
dir
- conda create --name gdal              // the actual name does not matter
- as long as it does not exist yet
- conda activate gdal
- conda build recipe

That *should* I think work since that is more or less what conda-forge does
in the azure pipeline - but I am no special expert on that recipe.

If that works - then you are probably going to have to change the meta.yml
to include fileGDB and probably change set_bld_opts.bat to change the build
options. And then run 'conda build recipe` again.

On Wed, 11 Nov 2020 at 13:00, Jon Morris <Jon.Morris at jbarisk.com> wrote:

> Hi Paul,
>
>
>
> Thanks for your reply. The only reason we're trying to build locally is to
> add FileGDB support - if there is a better way to add FileGDB write support
> to conda-forge GDAL, I'd love to hear it! The GDAL docs are very out of
> date when it comes to building on Windows - the "GDAL Windows Building
> example for Plugins" links to
> https://trac.osgeo.org/gdal/wiki/BuildingOnWindows.
>
>
>
> The only reason I'm building 3.1.4 is because when I started, 3.2.0 wasn't
> out yet...
>
>
>
> Thanks,
>
>
>
> Jon
>
>
>
> *From:* Paul Harwood <runette at gmail.com>
> *Sent:* 11 November 2020 09:18
> *To:* Jon Morris <Jon.Morris at jbarisk.com>
> *Cc:* gdal-dev at lists.osgeo.org
> *Subject:* Re: [gdal-dev] GDAL conda build
>
>
>
> I think we can be fairly certain that gdal-feedstock works, since it has
> passed in a clean container environment.
>
>
>
> The most obvious question is - I am assuming that you are using conda
> build - are you working in a clean conda env?
>
>
>
> Create a totally new conda env, activate that and then try again.
>
>
>
> I have very occasional noticed conda getting confused about versions in
> its package cache. You can also try `conda clean --all` to clear out the
> package cache.
>
> I am also curious. Sometimes I see messages go by and I think "why". I
> assume that you know your business much better than me but I do wonder what
> you are going to get from building the conda recipe locally that is not
> already built into the conda package? What have I missed?
>
> I am also curious - given you are going through the effort of creating the
> build - why 3.1.4 and not 3.2.0? Surely, you risk just building in a legacy
> problem?
>
>
>
> On Tue, 10 Nov 2020 at 08:12, Jon Morris <Jon.Morris at jbarisk.com> wrote:
>
> I've been trying to build a Windows conda package for GDAL 3.1.4, but am
> having problems with the poppler headers. I'm using the conda-forge recipe,
> which includes a line in the build script to detect the poppler version.
>
>
>
> FOR /F "tokens=1,2 delims=." %%a IN ("%poppler%") DO (
>
>   set POPPLER_MAJOR_VERSION=%%a
>
>   set POPPLER_MINOR_VERSION=%%b
>
> )
>
>
> https://github.com/conda-forge/gdal-feedstock/commit/320e66064c1288d582a3cadd8b573c863af654d6#diff-6f4a4b77035617ba53fd8a4d15347c44bb89f09d8086a0ffc1a5fca230ae2ed5R16
>
>
>
> This doesn't seem to be working, as when we get to compiling the pdf
> driver, the headers are missing.
>
>
>
> (gdal314) %SRC_DIR%\frmts>cd pdf   && nmake /nologo /f makefile.vc   &&
> cd ..   || exit 1
>
>         cl   /nologo /MP4 /MD /EHsc /Ox /FC /D_CRT_SECURE_NO_DEPRECATE
> /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786
> /wd4100 /wd4245 /wd4206 /wd4351 /wd4611  /DHAVE_SSE_AT_COMPILE_TIME
> /DHAVE_SSSE3_AT_COMPILE_TIME -I..\..\port -I..\..\ogr -I..\..\gcore
> -I..\..\alg -I..\..\ogr\ogrsf_frmts  -I..\..\gnm -I..\..\gnm\gnm_frmts
> -I..\..\apps /DHAVE_AVX_AT_COMPILE_TIME -I..\vrt -I..\mem
> -I..\..\ogr\ogrsf_frmts\mem  -DPOPPLER_MAJOR_VERSION=0
> -DPOPPLER_MINOR_VERSION=23 -DHAVE_POPPLER    -DGNM_ENABLED
> -DGDAL_COMPILATION -DNOMINMAX /c pdfdataset.cpp pdfio.cpp pdfobject.cpp
> pdfcreatecopy.cpp ogrpdflayer.cpp pdfwritabledataset.cpp pdfreadvectors.cpp
> pdfcreatefromcomposition.cpp
>
> pdfdataset.cpp
>
> pdfio.cpp
>
> pdfobject.cpp
>
> pdfcreatecopy.cpp
>
> c:\bin\anaconda3\conda-bld\gdal_1604943770331\work\frmts\pdf\pdfsdk_headers.h(54):
> fatal error C1083: Cannot open include file: 'goo/gtypes.h': No such file
> or directory (compiling source file pdfdataset.cpp)
>
>
>
> In pdfsdkheaders.h we can see it's the wrong poppler version that's
> causing the error:
>
>
>
> #if !(POPPLER_MAJOR_VERSION >= 1 || POPPLER_MINOR_VERSION >= 73)
>
> #include <goo/gtypes.h>
>
> #else
>
> typedef unsigned char Guchar;
>
> #endif
>
>
>
> The installed version of poppler is 20.11.0, so I don't know why I'm
> getting major version set to 0 and minor version set to 23.
>
>
>
> I'll also ask over at conda as this is most likely a conda build problem,
> but I thought I would also ask here if anyone has successfully built a
> conda package and knows how to get this recipe working.
>
>
>
> Many thanks!
>
>
>
> Jon
>
>
>
>
>
> *Jon Morris*
>
> Software Developer
>
>
>
> *COVID-19. During the current outbreak JBA remains open for business and
> we continue to deliver our services. However, we have adopted
> flexible/remote working as required. I will be receiving and reading email
> as normal but I may not always be available on the office number.*
>
>
>
> [image: JBA COVID-19 statement]
> <https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>
>
> *T* +44 (0) 1756 799919
> www.jbarisk.com
>
> [image: Visit our website] <http://www.jbarisk.com/>
> <https://www.linkedin.com/in/jon-morris-a2897b4/> [image: Follow us on
> Twitter] <https://twitter.com/jbarisk>
>
> *Find out more about us here: www.jbarisk.com <http://www.jbarisk.com/>
> and **follow us on Twitter @JBARisk <http://twitter.com/JBARisk> and
> LinkedIn
> <https://www.linkedin.com/company/2370847?trk=tyah&trkInfo=clickedVertical%3Acompany%2CclickedEntityId%3A2370847%2Cidx%3A2-1-2%2CtarId%3A1447414259786%2Ctas%3AJBA%20RISK%20MANAGEMENT>
> *
>
> The JBA Group supports the JBA Trust.
>
> All JBA Risk Management's email messages contain confidential information
> and are intended only for the individual(s) named. If you are not the named
> addressee you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by email if you have received this
> email by mistake and delete this email from your system.
>
>
> JBA Risk Management Limited is registered in England, company number
> 07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North
> Yorkshire, BD23 3FD, Telephone: +441756799919
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> [image: JBA COVID-19 statement]
> <https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201111/7489ec8b/attachment.html>