Cmake Qwt cmake files missing

ernie_hudds · 10 September 2024 13:31

I thought I had this cracked - but everytime I fix something something else doesn’t work. I have forced in the CMakeLists.txt for the build script to use Python 3 by using:
set(GPLATES_PYTHON_3 TRUE)
This got rid of the errors complaining about Python2.

Now I’m getting the following errors about Qwt. Its just baffling - I have set all the PATH variables and CMAKE_PREFIX_PATH variables and even changed the CMakeLists file to where all the directories are but it still complains about this missing files:
There are no such files: QwtConfig.cmake and qwt-config.cmake. I’m not sure where to go from here to get this building.
Can anyone help?

john.cannon · 12 September 2024 02:36

It’s more difficult to get CMake to find dependencies on Windows (in general). Is there a reason you’re compiling on Windows (rather than using the pre-built binaries)?

That really surprises me, because GPLATES_PYTHON_3 is true by default (and you have to explicitly change it in the CMake gui, for example, if you want a different value). You can try deleting the CMakeCache.txt file which stores/caches all these variables - that’ll restore things back to their default state - and then run CMake again.

Judging by your latest error messages, something got messed up at a fundamental level, probably if you changed the CMakeLists.txt file.

Now that you’ve installed/compiled all the dependencies, I would actually just delete your GPlates source code and build directories (they’ll be the same directory if you built in-place). Then double-check your CMAKE_PREFIX_PATH and PATH environment variables (for example, for Qwt). Then re-start CMake (so it sees any changes to those variables). Then extract the source code again and create a build directory that’s different than the source directory (called an out-of-place build - see BUILDS.Windows). Then select those source and build directories in CMake. Having a different build directory (ie, out-of-place build) means you can easily just delete the entire build tree and try again (without affecting the source tree).

ernie_hudds · 12 September 2024 08:37

Yes. The reason I’m building on windows is that I want to to use Gplates to be called from a C# WPF program - and I thought about building a C++/CLI wrapper around it so I can call from C#. I don’t want to use Python as I would have to bootstrap an environment with it. Now I’m wondering if I’m over-complicating this and there is an easier way to do what I want to do - but I always thought you had to build the source code when doing a CLI wrapper.

Since writing my original question I found some errors in the instructions - i.e. it directs you to go one directory too deep for the source code and if you step back a directory it works better. However there are still errors with building but I did get it to finally build albeit with a visual studio solution that had 5500 errors.

So I’m looking at doing it all over again in 2019. I just like pain it seems!

john.cannon · 13 September 2024 02:38

Interesting, I’m not familiar with that. If you’re just going to be using the GPlates command-line interface (ie, via the options shown with gplates.exe --help) then I’d be surprised if you had to build the source code. I’d imagine you’d only need to do that if you’re going to be directly calling some C++ functions in the source code. But I don’t know much about C# or WPF.

And if you’re just wrapping the command-line interface then it’ll be much more limited than what pyGPlates can do. But, as you say, you don’t want to bootstrap a Python environment.

Is it the part that says the following?

Set the 'source' directory to the root source directory (the one that has 'src' as a sub-directory).

If so, then yes, I’ll clear that up since one might think it’s referring to the src/ directory when it’s actually referring to its parent directory.

I might change the instructions to require 2019 actually. That’s what I’ve been using for quite a while now, and it’ll have better support for recent-ish C++ standards.

I’d be interested to hear how you go with a 2019 re-compile.

ernie_hudds · 13 September 2024 13:35

Hi John,

So first, I’m a bit new to GPlates and I haven’t used it much in anger, I have dabbled quickly with some python script and seen it do a bunch of stuff - but not being a geologist and more of a GIS Developer that develops for ESRI software - this is not something I have got too deep into - YET! I am sure I will have to get my head around GPlates and go a bit deeper - just to get things working the way they should.

Just to give some more context of what I’m trying to do - we want to use GPlates within ArcGIS Pro - within an add-in we are creating - the problem that we have is that pyGPlates needs its own Python environment - you can’t simply add pyGPlates to the default python environment that ships with ArcGIS Pro. One of my colleagues has shown me a demo of using pyGPlates within a python toolbox running inside of ArcGIS Pro - but you require another separate Python environment to go with it (some 1GB with pyGPlates installed there).

I want to use GPlates or pyGPlates functionality inside ArcGIS Pro but WITHOUT lugging around a separate Python environment with it - as this would undoubtedly create extra support calls for us!

In light of this I thought the cleanest way to get GPlates functionality accessible to the add-in would be to create C# wrappers around the GPlates functionality. If this can’t be done then you really are looking at bootstrapping some kind of python environment with pyGPlates which I think is a bit clunky.
However after you writing back to me - it looks like that I won’t be able to do the same functionality in GPlates vs pyGPlates as they are not on parity - which is not what I assumed. I thought that pyGPlates was a essentially a Python wrapper around GPlates. Stupid of me as I guess I should have researched that a bit better.

So I guess it would be good to know from you if I should halt what I am doing and think of a plan B - as what I intend to do with GPlates is simply not possible compared to pyGPlates.

Going back to Visual Studio 2019 build and the build instructions - I have got as far as GDAL build - but experiencing some problems - the latest version of GDAL does not support qmake anymore (so that makes the current instructions defunt) so I am trying to get ChatGPT to help me build it using CMAKE (based on old instructions). I think only 3.6.0 of GDAL will build without issue with CMAKE. So I’m going that route. I had been trying to get the very latest version of GDAL to work - but there are misssing libraries and urrrghgh.

Anyway I’d be interested to hear your thoughts on what you think might be the best way forward for me to get GPlates or pyGPlates embedded into an add-in for ArcGIS Pro 3.x.

Cheers
Simon.

john.cannon · 20 September 2024 07:12

Sorry for the late reply.

Does that apply to other Python modules as well, or just pyGPlates ? If it’s just a problem with pyGPlates, then that might be because you can’t currently install with pip (as in pip install pygplates), but that will be supported in the next pyGPlates release (very soon). However you can currently install pygplates using conda. But I’m not sure if any of this is useful in the ArcGIS environment or not.

You are right in that pyGPlates is a wrapper around GPlates, but it wraps its internal functionality. The GPlates functionality is mostly accessible through the graphical user interface - and since that’s not programmable, the only other way to access it is through the GPlates command-line interface - which is much more limited (but still useful since projects like rgplates use it).

PyGPlates also makes the internal functionality more accessible to end users (by designing and documenting an abstraction layer around it, making it easier to use). To access the internal functionality directly (ie, via the C++ source code instead of via pyGPlates) would require a higher level of understanding of the GPlates C++ code base - which, while it was (and continues to be) well-designed, it is still not something to be taken lightly (ie, needs a fairly significant investment in time to get up to speed with).

Yes, GDAL >= 3.5 uses CMake, but I had link errors using it, so I just used GDAL 3.4.3 instead for now (ie GDAL < 3.5).

I’ve updated the build instructions (will be in next release). Here is the section relevant to GDAL:

GDAL

    1. Get GDAL 3.x source code from https://github.com/OSGeo/gdal/releases
    2. Extract to a location on your hard drive (eg, "C:\SDK\GDAL\gdal-3.8.3").
    3. Read the instructions for compiling and installing GDAL.
       GDAL >= 3.5 uses CMake (see https://gdal.org/development/building_from_source.html).
       GDAL < 3.6 uses nmake (see https://trac.osgeo.org/gdal/wiki/BuildingOnWindows).
       Note that currently building GDAL >= 3.5 (eg, 3.8.3) results in a link error concerning hdf5-shared.lib (which is meant to be a CMake target, no library).
       So currently we just use GDAL 3.4.3.

       For GDAL >= 3.5 this involves:
       o Create a 'build' sub-directory inside your extracted proj source directory (eg, "C:\SDK\GDAL\gdal-3.8.3\build\") and step into it:
           mkdir build
           cd build
       o Configure for building:
         Here we use Visual Studio 2019 ('-G "Visual Studio 16 2019"') in 64-bit mode ('-A x64').
         We set the GDAL install path using '-D CMAKE_INSTALL_PREFIX ...' a directory that is different than the root of the extracted source tree.
         For example, "C:\SDK\GDAL\gdal-3.8.3\msvc2019_64". This ensures GPlates/pyGPlates will find the correct GDAL CMake config files (the ones created when installing GDAL).
         You can specify the Proj/NetCDF/SQLite3 include/library/exe locations using '-D CMAKE_PREFIX_PATH ...'.
         Note that if they are already in the CMAKE_PREFIX_PATH or PATH environment variables then this is not necessary.
         And the final '..' tells CMake the root location of the source tree (ie, parent directory of 'build').
           cmake -G "Visual Studio 16 2019" -A x64 \
                 -D CMAKE_INSTALL_PREFIX:PATH=C:\SDK\GDAL\gdal-3.8.3\msvc2019_64 \
                 -D GDAL_USE_SQLITE3:BOOL=ON \
                 -D GDAL_USE_NETCDF:BOOL=ON \
                 ..
       o Build GDAL (as a release build):
           cmake --build . --config Release
       o Install GDAL (into the CMAKE_INSTALL_PREFIX location specified above):
           cmake --build . --config Release --target install
       
       For GDAL < 3.6 this involves:
        o Edit the "nmake.opt" file under the section labelled "# Uncomment the following to enable NetCDF format.",
          - Uncomment the following four lines and specify the location of the NetCDF library (see NetCDF above).
          - For example, after editing, you might have something like:
            NETCDF_PLUGIN = NO
            NETCDF_SETTING=yes
            NETCDF_LIB=C:\SDK\NetCDF\netcdf-4.9.2\lib\netcdf.lib
            NETCDF_INC_DIR=C:\SDK\NetCDF\netcdf-4.9.2\include
       o Edit the "nmake.opt" by uncommenting '#NETCDF_HAS_NC4 = yes':
          - This enables NetCDF version 4 support (which uses HDF5).
          - For example, after editing, you should have:
            NETCDF_HAS_NC4 = yes
       o Edit the "nmake.opt" file under the section labelled "# PROJ stuff (required dependency: PROJ >= 6)",
          - Uncomment the following two lines and specify the location of the PROJ library (see PROJ above).
          - For example, after editing, you might have something like:
            PROJ_INCLUDE = -IC:\SDK\PROJ\proj-9.3.1\msvc2019_64\include
            PROJ_LIBRARY = C:\SDK\PROJ\proj-9.3.1\msvc2019_64\lib\proj.lib
       o Edit the "nmake.opt" file under the section labelled "SQLite Libraries",
          - Uncomment the following two lines and specify the location of the SQLite3 library (see SQLite3 above).
          - For example, after editing, you might have something like:
            SQLITE_INC=-Ic:\SDK\SQLite\sqlite-amalgamation-3450000
            SQLITE_LIB=c:\SDK\SQLite\sqlite-amalgamation-3450000\sqlite3_i.lib
            Note that we're not using the spatialite extension to SQLite which would require installing the spatialite amalgamation
            (instead the SQLite3 amalgamation) and also specifying the '-DHAVE_SPATIALITE' and '-DSPATIALITE_AMALGAMATION' flags in 'SQLITE_INC'.
       o Start a Visual Studio command prompt (64-bit).
          Run 'nmake /f makefile.vc' with options specifying compiler, 64 bit and the install prefix.
          For example, to compile using Visual Studio 2019 as 64-bit and install into the "msvc2019_64" sub-directory of source code root, type:
            nmake /f makefile.vc MSVC_VER=1929 WIN64=1 GDAL_HOME=C:\SDK\GDAL\gdal-3.4.3\msvc2019_64 devinstall
          - If 'MSVC_VER' is not specified it appears (in "nmake.opt") to default to 1900 (Visual Studio 2015). At least for GDAL 2.3 (and still there for 3.3).
            Above we specify MSVC_VER=1929 which corresponds to Visual Studio 2019 version 16.10 (and 16.11).
          - 'WIN64=1' specifies a 64-bit build.
          - 'GDAL_HOME' specifies the install location.
            For example, "C:\SDK\GDAL\gdal-3.4.3\msvc2019_64" specifies the "msvc2019_64" sub-directory of the source code root "C:\SDK\GDAL\gdal-3.4.3".
          - If you want a debug build then add 'DEBUG=1'.
            NOTE: It appears both debug and release builds use the same filenames (so they just overwrite each other).
                  Might need to pick one or the other.
          - The 'devinstall' target ensures the libraries and include files are installed (in addition to GDAL executables and data from 'install' target).

    4. Add the *install* 'bin' directory to the PATH environment variable (eg, "C:\SDK\GDAL\gdal-3.8.3\msvc2019_64\bin" or "C:\SDK\GDAL\gdal-3.4.3\msvc2019_64\bin").
       This is so the GDAL DLL can be found at run-time.
    5. Add the GDAL *install* directory to the CMAKE_PREFIX_PATH environment variable (eg, "C:\SDK\GDAL\gdal-3.8.3\msvc2019_64" or "C:\SDK\GDAL\gdal-3.4.3\msvc2019_64").
       This enables CMake to find GDAL when configuring GPlates/pyGPlates (see BUILD.Windows).
       Note that this is not strictly necessary since CMake can find the GDAL install prefix using the PATH environment variable (CMake strips off 'bin').
    6. Set the GDAL_HOME environment variable to the installed GDAL directory (eg, "C:\SDK\GDAL\gdal-3.8.3\msvc2019_64" or "C:\SDK\GDAL\gdal-3.4.3\msvc2019_64").
       This enables GPlates to deploy GDAL plugins.
    7. Set the GDAL_DATA environment variable to the installed GDAL data directory (eg, "C:\SDK\GDAL\gdal-3.8.3\msvc2019_64\data" or "C:\SDK\GDAL\gdal-3.4.3\msvc2019_64\data").
       This enables GDAL to find its resource data.
    
    NOTE that GDAL 2.3 (and above) use C++11 features which requires Visual Studio 2015 (or above).