Expose EXE_SQLITE3 as CMake variable in order to allow using custom SQLite3 binaries

[aleksandaratanasov]

Currently the following CMake code covers the library and binary of SQLite3:

find_program(EXE_SQLITE3 sqlite3)
if(NOT EXE_SQLITE3)
  message(SEND_ERROR "sqlite3 binary not found!")
endif()

# Deprecated variables since PROJ 9.4.0
if(DEFINED SQLITE3_INCLUDE_DIR)
  message(DEPRECATION "Use SQLite3_INCLUDE_DIR instead of SQLITE3_INCLUDE_DIR")
  set(SQLite3_INCLUDE_DIR ${SQLITE3_INCLUDE_DIR})
endif()
if(DEFINED SQLITE3_LIBRARY)
  message(DEPRECATION "Use SQLite3_LIBRARY instead of SQLITE3_LIBRARY")
  set(SQLite3_LIBRARY ${SQLITE3_LIBRARY})
endif()

The strange thing here is that SQLite3_INCLUDE_DIR and SQLite3_LIBRARY indicate the ability to use a custom SQLite3 library. But the same logic does not apply to the executable. If one builds the SQLite3 from source (like I do by invoking ExternalProject_Add() in my own project), it is very easy to also produce the executable.

Further, I believe that it should not be possible to mix two different versions of the two components (the library and the binary), which is something that is also allowed right now.

I suggest the following patch:

if(NOT DEFINED EXE_SQLITE3)
  find_program(EXE_SQLITE3 sqlite3)
  if(NOT EXE_SQLITE3)
    message(SEND_ERROR "sqlite3 binary not found!")
  endif()
endif()

Since I am new to the PROJ project, I cannot tell if this will have any repercussions down the rest of the configuration and build process.

[rouault]

I see that EXE_SQLITE3 is a CMake cache variable. Did you actually try to override it? I'd assume this should work

Further, I believe that it should not be possible to mix two different versions of the two components (the library and the binary), which is something that is also allowed right now.

There's no strong reason to tie the sqlite3 lib and bin versions. That might be "saner" when explaining one's environmenent, but definitely no strong requirement