# Correct usage of FindSQLite3 module in Windows
**URL:** https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174
**Category:** Usage
**Created:** [November 9, 2019, 12:29am UTC](https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174 "2019-11-09T00:29:41Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@arcesino](https://discourse.cmake.org/u/arcesino)
#### Post date: [November 9, 2019, 12:29am UTC](https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174/1 "2019-11-09T00:29:41Z")
Hi all,
I’ve been using module **FindSQLite3.cmake** that comes bundled into CMake’s installation for finding SQLite3’s include dir and library under Linux and macOS. Recently, I’m working on porting one of those projects to Windows and ran into the issue that the module is not able to find SQLite3. So, my question is:
Can this module be used in Windows?
and if so
What additional configuration is required?
I’m wondering if the issue is related to where I installed SQLite’s binaries and sources. This is how my installation looks:
- C:\sdk\sqlite-3.30.1
- include\
- shell.c
- sqlite3.c
- sqlite3.h
- sqlite3ext.h
- lib\
- sqlite3.def
- sqlite3.dll
I noticed that if in my **CMakeList.txt** file I set variables _SQLite3\_INCLUDE\_DIR_ and _SQLite3\_LIBRARY_ to the corresponding paths matching my SQLite3 installation, the module executes with no errors but if I have to explicitly set those paths then to use the module makes no sense anymore. Nonetheless, I’m still calling the modules in order to keep my build cross-platform. This is the relevant part:
```
add_executable(sqlite-cache sqlite-cache/main.cpp)
if(WIN32)
set(SQLite3_INCLUDE_DIR C:\\sdk\\sqlite-3.30.1\\include)
set(SQLite3_LIBRARY_DIR C:\\sdk\\sqlite-3.30.1\\lib)
set(SQLite3_LIBRARY sqlite3.dll)
endif()
find_package(SQLite3 REQUIRED)
target_include_directories(sqlite-cache PRIVATE ${SQLite3_INCLUDE_DIRS})
target_link_directories(sqlite-cache PRIVATE ${SQLite3_LIBRARY_DIR})
target_link_libraries(sqlite-cache ${SQLite3_LIBRARIES})
```
Thanks in advance!
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 9, 2019, 2:16am UTC](https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174/2 "2019-11-09T02:16:50Z")
Hmm. You seem to be missing a `sqlite3.lib` somewhere. On Windows, that is used for linking (the `.dll` is used at runtime). Unless that `.def` is supposed to be used instead, though I doubt that.
---
### Author:  [@arcesino](https://discourse.cmake.org/u/arcesino)
#### Post date: [November 10, 2019, 9:31am UTC](https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174/3 "2019-11-10T09:31:40Z")
Hi Ben,
My understanding is that the `.dll` is required for both: linking and at runtime.
After looking closer at the **FindSQLite3.cmake** module’s source code and further investigating CMake commands [find\_path](https://cmake.org/cmake/help/latest/command/find_path.html) & [find\_library](https://cmake.org/cmake/help/latest/command/find_library.html), which are used by the module to set variables _SQLite3\_INCLUDE\_DIR_ & \* SQLite3\_LIBRARY\* respectively, I came up with the following solution:
```
add_executable(sqlite-cache sqlite-cache/main.cpp)
if(WIN32)
set(CMAKE_PREFIX_PATH C:\\sdk\\sqlite-3.30.1)
endif()
find_package(SQLite3 REQUIRED)
target_include_directories(sqlite-cache PRIVATE ${SQLite3_INCLUDE_DIRS})
target_link_libraries(sqlite-cache ${SQLite3_LIBRARIES})
```
According to the documentation of _find\_path_ and _find\_library_ commands, one of the steps of their search algorithm is to look inside paths specified in **CMAKE\_PREFIX\_PATH** ; per these commands documentation will search for include paths as:
> `/include/` if `CMAKE_LIBRARY_ARCHITECTURE` is set, and `/include` for each `` in `CMAKE_PREFIX_PATH`
and for libraries as:
> `/lib/` if `CMAKE_LIBRARY_ARCHITECTURE` is set, and `/lib` for each `` in `CMAKE_PREFIX_PATH`
As you can see, the commands enforce that headers must be inside an `include/` dir and libraries inside a `lib/` dir and since my SQLite installation happens to have that format, then the solution above works. The search algorithm also looks in directories declared in system env vars like _PATH_ and _INCLUDE_, but I prefer this approach since headers & libraries will be found faster.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 10, 2019, 3:31pm UTC](https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174/4 "2019-11-10T15:31:22Z")
> [@arcesino](#):
>
> My understanding is that the `.dll` is required for both: linking and at runtime.
That’s not how Windows linking works; just the `.lib` is necessary. Maybe SQLite is doing something weird to make the `.dll` suitable for the linker, but in general, they aren’t used at all.
> [@arcesino](#):
>
> As you can see, the commands enforce that headers must be inside an `include/` dir and libraries inside a `lib/` dir and since my SQLite installation happens to have that format, then the solution above works. The search algorithm also looks in directories declared in system env vars like _PATH_ and _INCLUDE_ , but I prefer this approach since headers & libraries will be found faster.
That works, but the defaults for where it looks for headers and libraries is not set in stone (mostly taking issue with your use of “enforce” rather than “defaults to”). There are lots of libraries that do things like `lib/x64` (TBB, OpenCV), have headers in `lib` (if they’re architecture-specific), or have their headers completely elsewhere (NumPy puts them beside the module files). CMake supports any of these with the appropriate `SUFFIXES` or other `find_*` arguments.
---
### Author:  [@int\_main](https://discourse.cmake.org/u/int_main)
#### Post date: [May 14, 2025, 3:24pm UTC](https://discourse.cmake.org/t/correct-usage-of-findsqlite3-module-in-windows/174/5 "2025-05-14T15:24:06Z")
On Windows `sqlite3.lib` can be composed from `sqlite3.dll` and `sqlite3.def` with `Developer Command Prompt for VS 20..` with `lib` program. So no CMake _search paths_ hardcoding will be required.
>