[2/3] Add CMake build system; remove obsolete build configurations

[fdcastel]

This is the second of 3 planned PRs aimed at improving the project infrastructure, as outlined in the plan discussed in PR #275.

Summary

This PR adds a CMake build system for the Firebird ODBC driver and removes obsolete build configurations, vendored headers, and non-functional test projects.

The driver source code is unchanged: the CMake-built DLL is binary-compatible with the existing VS 2022 solution build.

What's new

CMake build system

File	Purpose
CMakeLists.txt (root)	Builds the FirebirdODBC.dll driver + IscDbc static lib + test suite
IscDbc/CMakeLists.txt	IscDbc static library (database connectivity layer)
cmake/FetchFirebirdHeaders.cmake	Downloads Firebird 5.0.2 public headers from GitHub at build time
cmake/GetVersionFromGit.cmake	Extracts version from git tags (vMAJOR.MINOR.PATCH)
cmake/Version.h.in	Template for auto-generated Version.h

Build instructions (CMake)

cmake -B build -G "Visual Studio 17 2022" -A x64
cmake --build build --config Release

The test suite from PR #276 is integrated and runs via CTest:

set FIREBIRD_ODBC_CONNECTION=Driver={Firebird ODBC Driver};Dbname=localhost:C:\path\to\test.fdb;Uid=SYSDBA;Pwd=masterkey;
ctest --test-dir build --output-on-failure

Build instructions (VS 2022 solution)

The existing solution at Builds/MsVc2022.win/OdbcFb.sln continues to work but now requires a one-time CMake configure step to fetch Firebird headers:

cmake -B build          # fetches Firebird headers to build/_deps/

Then open Builds/MsVc2022.win/OdbcFb.sln in Visual Studio and build as usual.

What's removed

Obsolete build configurations (14 directories)

All removed directories contained build files for discontinued platforms, compilers, or IDEs. Only Builds/MsVc2022.win/ is kept.

Directory	Reason
Builds/Bcc55.win/	Borland C++ 5.5 — discontinued compiler
Builds/CC.solaris/	Solaris — discontinued by Oracle
Builds/Gcc.darwin/	macOS makefiles — replaced by CMake
Builds/Gcc.freeBSD/	FreeBSD makefiles — replaced by CMake
Builds/Gcc.lin/	Linux makefiles — replaced by CMake
Builds/Gcc.solaris/	Solaris — discontinued by Oracle
Builds/MinGW_Dev-Cpp.win/	MinGW/Dev-C++ — outdated IDE
Builds/MsSDK64.win/	Microsoft SDK command-line — replaced by CMake
Builds/MsVc60.win/	Visual Studio 6.0 (1998)
Builds/MsVc70.win/	Visual Studio .NET 2002
Builds/MsVc80.win/	Visual Studio 2005
Builds/MsVc90.win/	Visual Studio 2008
Builds/VAC.aix/	IBM AIX — discontinued
Builds/aCC.HP/	HP-UX — discontinued

Also removed: Builds/makefile.environ, Builds/makefile.sources, Builds/delDependMT.bat, makefile.in, IscDbc/makefile.in.

Vendored headers

Directory/File	Replacement
FBClient.Headers/ (60 files, ~25K lines)	Downloaded at build time via cmake/FetchFirebirdHeaders.cmake (pinned to Firebird v5.0.2)
Headers/SQL.H, Headers/SQLEXT.H	System Windows SDK (already on every Windows dev machine)

Headers/OdbcUserEvents.h (a project-specific header, not a vendored SDK file) was moved to the project root.

Non-functional old test projects

Directory	Reason
JdbcTest/	JDBC-style test — references classes that don't exist in the driver
Test/	Old standalone test app — not buildable
TestInstall/	Installation test — references VS 6.0 project format

The Google Test suite from PR #276 (tests/) replaces these.

Build artifacts and MinGW remnants

• OdbcJdbc.exp, IscDbc/IscDbc.exp, OdbcJdbcSetup/OdbcJdbcSetup.exp — linker export files (build output, not source)
• OdbcJdbcMinGw.def, OdbcJdbcSetup/OdbcJdbcSetupMinGw.def — MinGW-specific definition files (MinGW build removed)
• OdbcJdbc.dll.manifest → renamed to FirebirdODBC.dll.manifest to match the reference in OdbcJdbc.rc

What's changed in existing files

File	Change
OdbcConnection.h	#include "Headers/OdbcUserEvents.h" → #include "OdbcUserEvents.h"
Builds/MsVc2022.win/OdbcFb.vcxproj	Include path updated from FBClient.Headers to build/_deps/firebird_headers-src/src/include; header reference updated for moved OdbcUserEvents.h
Builds/MsVc2022.win/OdbcFb.vcxproj.filters	Header reference updated for moved OdbcUserEvents.h
tests/CMakeLists.txt	Updated from standalone project to integrated sub-project; uses FetchContent for Google Test instead of find_package
.gitignore	Added CMake build artifact patterns

What's NOT changed

• No driver source code changes — same .cpp/.h files, same behavior
• No source reorganization — source remains at root level
• No performance changes — no LTO, no -march=native, etc.
• No feature additions — no ODBC 3.8, no GUID, no timeout, etc.

Validation

Both build systems produce a working FirebirdODBC.dll with identical exports (120 symbols):

Build system	DLL size	Exports	Test suite
CMake (Release x64)	865 KB	120	375 tests, 375 skipped (no DB), 0 failures
VS 2022 (Release x64)	2,478 KB	120	—

The VS 2022 DLL is larger due to incremental linking and debug information defaults in the solution file. The exported symbol sets are identical.

Requirements

• CMake 3.15+
• Visual Studio 2022 with C++ ATL component (for ResourceManagerSink.cpp and TransactionResourceAsync.cpp)
• Internet access during first build (to download Firebird headers and Google Test)

[irodushka]

Hi @fdcastel

Have you ever tested this PR on Linux?..

[fdcastel]

Have you ever tested this PR on Linux?..

DOH! 🤦🏻‍♂️

No! I only ran them on my (Windows) machine, sorry. 😞

I rely on GitHub Actions for the Linux build and tests (those are coming in the third PR, the next one).

I’ll work on the next PR, basing it on this one, so I can verify that everything works across all platforms.

[irodushka]

So it shouldn't surprise you that the Linux build is not working)

[fdcastel]

So it shouldn't surprise you that the Linux build is not working)

Definitely not 🤣.

I’ll take care of this over the weekend. Please hold.

[irodushka]

Aha)
And just another question - you remember my PR #248 - the first approach to implement cmake.

Your PR lacks many features that exist in my one. I'm not speaking about an ugly makefile.sources parser)) it's obviously not needed and was made to support the native MSBuild compatibility. But what about the rest? You've dropped them consciously or by accident?

[fdcastel]

Aha) And just another question - you remember my PR #248 - the first approach to implement cmake.

Your PR lacks many features that exist in my one. I'm not speaking about an ugly makefile.sources parser)) it's obviously not needed and was made to support the native MSBuild compatibility. But what about the rest? You've dropped them consciously or by accident?

I dropped everything aiming to keep it simpler. But -- of course -- this is just the initial concept and may change.

The idea here was to get initial feedbacks. I had no idea what you really want to keep from the legacy code. 😉

Please point here in the code review what you’d like to retain from the previous sources, and I’ll backport it. 👍🏻

[fdcastel]

P.s.: Great feedback so far, thanks! Please keep it coming!!!

Share anything you’re not happy with here, and I’ll address it in an updated version of this PR over the next few days.

[irodushka]

+++ maybe is makes sense to move all the source code to /src folder. It's a kind of standard approach. And just put
add_subdirectory(src)
to the up-level makefile...

[irodushka]

Aha) And just another question - you remember my PR #248 - the first approach to implement cmake.
Your PR lacks many features that exist in my one. I'm not speaking about an ugly makefile.sources parser)) it's obviously not needed and was made to support the native MSBuild compatibility. But what about the rest? You've dropped them consciously or by accident?

I dropped everything aiming to keep it simpler. But -- of course -- this is just the initial concept and may change.

The idea here was to get initial feedbacks. I had no idea what you really want to keep from the legacy code. 😉

Please point here in the code review what you’d like to retain from the previous sources, and I’ll backport it. 👍🏻

The major things I meant are:

1. CMAKE_BUILD_TYPE processing, setting Release as the default value
2. Explicit compiler options for different build types (optimizations, etc)
3. CPU arch detection (should be moved to a separate cmake include file) and the -msse4.1 flag. This flag means that g++ will use the sse4.1 SIMD instructions (and not higher!) while auto-vectorization if -O3 is set. We suppose that in 2026 even the cheapest x64 CPU has sse4.2 on board)
4. Target (maybe an option) for static lib build (legacy, but maybe needed by someone)

[fdcastel]

+++ maybe is makes sense to move all the source code to /src folder.

I FULLY agree. That would be cleaner.

But let’s hold off on that for now. I implemented it in v4, so we’ll get there soon.

[fdcastel]

Missing features from PR #248

a. CMAKE_BUILD_TYPE processing, setting Release as default

Fixed. Added:

if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build." FORCE)
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug Release RelWithDebInfo MinSizeRel)
endif()

b. Explicit compiler options for different build types

Fixed. Added per-config optimization flags for GCC/Clang:

add_compile_options(
    "$<$<CONFIG:Debug>:-O0;-g3;-D_DEBUG;-DDEBUG;-DLOGGING;-fexceptions>"
    "$<$<CONFIG:Release>:-O3;-DNDEBUG;-ftree-loop-vectorize>"
    "$<$<CONFIG:RelWithDebInfo>:-O2;-g;-DNDEBUG>"
    "$<$<CONFIG:MinSizeRel>:-Os;-DNDEBUG>"
)

c. CPU arch detection and -msse4.1 flag

Fixed. Added architecture detection (x86, x86_64, ARM64, generic) and
-msse4.1 for x86/x86_64:

set(FBODBC_ARCH ${CMAKE_HOST_SYSTEM_PROCESSOR})

if(FBODBC_ARCH STREQUAL "x86" OR FBODBC_ARCH STREQUAL "i686")
    add_definitions(-DFBODBC_ARCH_X86)
elseif(FBODBC_ARCH STREQUAL "x86_64" OR FBODBC_ARCH STREQUAL "AMD64")
    add_definitions(-DFBODBC_ARCH_X86_64)
elseif(FBODBC_ARCH STREQUAL "aarch64" OR FBODBC_ARCH STREQUAL "arm64" OR FBODBC_ARCH STREQUAL "ARM64")
    add_definitions(-DFBODBC_ARCH_ARM64)
else()
    add_definitions(-DFBODBC_ARCH_GENERIC)
endif()

if(FBODBC_ARCH_X86 OR FBODBC_ARCH_X86_64)
    add_compile_options(-msse4.1)
endif()

d. Target for static lib build

Not included in this PR. Can be added as an option if there's demand:

option(BUILD_STATIC_LIB "Also build a static library" OFF)

Let me know if you'd like this in the current PR or a future one.

[fdcastel]

All three existing workflows have been updated:

Workflow	Before	After
linux.yml	make in Builds/Gcc.lin	cmake -B build && cmake --build build
msbuild.yml	MSBuild only	Added cmake -B build step to fetch Firebird headers
rpi_arm64.yml	make in Builds/Gcc.lin	cmake -B build && cmake --build build

All workflows also trigger on the new-build-system and new-build-system-no-pr branches for testing (this must be reverted to master-only when merging).

[fdcastel]

@irodushka The fixes are in!

When you have a moment, please take a look and share your thoughts, suggestions, or any feedback here.

[irodushka]

@fdcastel
Sorry for the delay, have a lot to do besides FB)

Linux build is ok.
MS build - generally ok, but I have some questions (see in PR)

I'm ready to merge this PR as we quickly resolve those questions.

[fdcastel]

@irodushka The VS include path issue is now fixed — I added a CMakePresets.json that ensures Visual Studio's built-in CMake mode uses build/ as the binary directory (matching the command-line cmake -B build).

All three CI workflows are green (Linux, MSBuild, RaspberryPI ARM64).

Let me know if there's anything else!

[irodushka]

Well, okay! It's the final countdown!

[irodushka]

@fdcastel
Oops, someone has forgotten to update msbuild_arm64.yaml )

UPD: Well, it's really green now. And FYI: I've also updated buildno 21->22 (in WriteBuildNo.h)

[irodushka]

Continuing with the astronomical theme - this merge is one small step for a man, one giant leap for mankind!

[fdcastel]

@fdcastel Oops, someone has forgotten to update msbuild_arm64.yaml )

UPD: Well, it's really green now. And FYI: I've also updated buildno 21->22 (in WriteBuildNo.h)

We’ll be changing all of this soon, too 😉

Working on the rebase for [3/3], now in a few hours. Feel free to make any other changes and let me know when everything is fine.