This document contains the complete build, test, installation, cleaning, and compiler environment instructions for the dateconv library.
Use the configuration command that corresponds to your library type, target platform, compiler, and build system. The sections below provide the available configuration commands for each supported setup.
For an overview of the project, licensing details, and general usage instructions, please refer to README.html.
| Workflow | Typical platforms | Compiler or toolchain | Build executor |
|---|---|---|---|
| Standalone GNU Makefile | GNU/Linux, macOS, MinGW environments | GCC or Clang | GNU Make |
| GNU Autotools | GNU/Linux, macOS, and compatible Unix-like environments | GCC or Clang | GNU Make |
| CMake with Unix Makefiles | GNU/Linux and macOS | GCC or Clang | GNU Make |
| CMake with MinGW Makefiles | Windows | MinGW-w64 GCC | GNU Make |
| CMake with Ninja | GNU/Linux, macOS, and Windows | GCC, Clang, MinGW, or MSVC | Ninja |
| CMake Presets with Ninja | GNU/Linux, macOS, and Windows | Toolchain selected by CMake | Ninja |
| Meson | GNU/Linux, macOS, and Windows | GCC, Clang, MinGW, or MSVC | Meson backend, normally Ninja |
| CMake with NMake | Windows | Microsoft Visual C/C++ | NMake |
dist directory is used as the installation prefix in these examples.
test target builds the test executable without running it.
check target builds the test when necessary and then runs it.
$PWD are intended for a Unix-like shell such as MSYS2. Native Command Prompt uses %CD%, as shown in the NMake section.
The dateconv library uses functions declared in <math.h>, such as sin() and floor(). The supplied build systems handle the platform-specific link dependency automatically.
On GNU/Linux and other platforms where the C math library is provided separately, the shared library is linked with libm, and static library consumers receive -lm through the build target or the Libs.private field in libdateconv.pc.
On macOS, native Windows toolchains, and other platforms where the C math library is not provided as a separate library, no additional math library link option is normally required.
When linking against the shared library, no additional math library option is required. The shared library already carries its required dependencies, and the dynamic linker resolves them automatically at runtime.
This also applies to static linking on platforms where the C math library is not provided as a separate library, such as macOS, native Windows toolchains, and some Unix-like systems. On these platforms, no additional -lm option is required.
cc application.c -I/path/to/include -L/path/to/lib -ldateconv -o application
On platforms where the C math library is provided separately, such as GNU/Linux, static linking requires adding -lm manually. Keep the library order shown below, because libraries that provide required symbols must appear after the libraries that use them:
cc application.c -I/path/to/include -L/path/to/lib -ldateconv -lm -o application
For installed builds, prefer pkg-config so the correct platform-specific dependency is selected automatically:
pkg-config --cflags --libs libdateconv
pkg-config --cflags --libs --static libdateconv
The first command is for normal shared library linking. The second command is for static linking and includes -lm only on platforms where it is required.
The standalone Makefile can build both library variants, only the shared library, or only the static library. The build selection commands are independent alternatives.
make
make shared
make static
make performs the default build.
make shared builds the shared library.
make static builds the static library.
make test
make check
make install prefix="$PWD/dist"
make clean
make test only creates the test executable. Use make check when the test must also be executed. The installation command places the files under the specified dist prefix.
Autotools uses configure.ac and Makefile.am to generate the portable configure script and Makefile templates. Running autoreconf is useful after changing Autotools input files; projects that already include a generated configure script can normally start directly with one of the ./configure commands.
autoreconf -fiv
Choose one of the following commands:
./configure --prefix="$PWD/dist"
./configure --prefix="$PWD/dist" --enable-shared --disable-static
./configure --prefix="$PWD/dist" --disable-shared --enable-static
make
make test
make check
make install
make clean
The installation prefix was already recorded by ./configure, so make install uses the selected dist path automatically.
CMake first generates Makefiles and stores its configuration in the build directory. After configuration, enter that directory and invoke the generated targets with make.
Choose one configuration command. The explicit Unix Makefiles generator and the command without -G are both provided because Unix Makefiles are commonly the default when GNU Make is available.
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -G"Unix Makefiles"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON
The first two commands use the project's default configuration. The third creates a shared-only configuration, and the fourth creates a static-only configuration.
These commands select CMake's MinGW Makefiles generator. They are intended for an environment where the MinGW compiler and GNU Make are available and where $PWD is supported, such as an MSYS2 shell.
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -G"MinGW Makefiles"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF -G"MinGW Makefiles"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -G"MinGW Makefiles"
After running one of the configuration commands above, enter the generated build directory:
cd build
make
make test
make check
make install
make clean
make builds the library targets. The remaining commands build the test, execute it, install the configured artifacts, or remove generated build outputs.
CMake can generate Ninja build files instead of Makefiles. Choose the setup command that matches the desired library type.
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -G"Ninja"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF -G"Ninja"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="$PWD/dist" -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -G"Ninja"
cd build
ninja
ninja test
ninja check
ninja install
ninja clean
When this workflow is used with MSVC, first complete Preparing an MSVC environment on Windows. Then run the CMake/Ninja configuration and build commands above from the same initialized Visual Studio developer shell.
The included CMakePresets.json provides separate build directories and target presets for both, shared-only, and static-only builds. A configure preset must be run before its corresponding build presets.
cmake --preset ninja
cmake --build --preset ninja
cmake --build --preset ninja-test
cmake --build --preset ninja-check
cmake --build --preset ninja-install
cmake --build --preset ninja-clean
# OR
ninja -C build/ninja
ninja -C build/ninja test
ninja -C build/ninja check
ninja -C build/ninja install
ninja -C build/ninja clean
The commands after # OR invoke the same generated Ninja targets directly instead of going through CMake's build-preset interface.
cmake --preset ninja-shared
cmake --build --preset ninja-shared
cmake --build --preset ninja-shared-test
cmake --build --preset ninja-shared-check
cmake --build --preset ninja-shared-install
cmake --build --preset ninja-shared-clean
# OR
ninja -C build/ninja-shared
ninja -C build/ninja-shared test
ninja -C build/ninja-shared check
ninja -C build/ninja-shared install
ninja -C build/ninja-shared clean
cmake --preset ninja-static
cmake --build --preset ninja-static
cmake --build --preset ninja-static-test
cmake --build --preset ninja-static-check
cmake --build --preset ninja-static-install
cmake --build --preset ninja-static-clean
# OR
ninja -C build/ninja-static
ninja -C build/ninja-static test
ninja -C build/ninja-static check
ninja -C build/ninja-static install
ninja -C build/ninja-static clean
When these presets are used with MSVC, first complete Preparing an MSVC environment on Windows. Then run the relevant both, shared-only, or static-only preset sequence above from the same initialized Visual Studio developer shell.
Meson configures the project in the build directory and normally uses Ninja as its backend. Choose the setup command that matches the desired library type.
meson setup build --prefix="$PWD/dist" --libdir=lib
meson setup build --prefix="$PWD/dist" --libdir=lib -Ddefault_library=both
meson setup build --prefix="$PWD/dist" --libdir=lib -Ddefault_library=shared
meson setup build --prefix="$PWD/dist" --libdir=lib -Ddefault_library=static
The first command uses the project's default library selection. The remaining commands explicitly request both, shared-only, or static-only output.
--libdir=lib keeps libraries and pkg-config files directly under dist/lib; otherwise, on Linux, Meson may choose a multiarch directory such as dist/lib/x86_64-linux-gnu.
cd build
meson compile
meson compile dateconv_test
meson test
meson install
meson compile --clean
The normal compile command builds the library. The dateconv_test command explicitly builds the test executable, while meson test runs the registered test.
To make Meson select the Microsoft compiler, first complete Preparing an MSVC environment on Windows. Then run the Meson setup and compile commands above from the same initialized Visual Studio developer shell.
NMake is the Microsoft Make-compatible build executor supplied with Visual Studio. It requires an initialized MSVC developer environment.
Before using the NMake generator, complete Preparing an MSVC environment on Windows. Run the NMake configuration and build commands below from that same initialized Visual Studio developer shell.
Run one of these commands from a native Windows Command Prompt or a Visual Studio developer shell. %CD% expands to the current directory.
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="%CD%\dist" -DCMAKE_BUILD_TYPE=Release -G"NMake Makefiles"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="%CD%\dist" -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF -G"NMake Makefiles"
cmake . -Bbuild -DCMAKE_INSTALL_PREFIX="%CD%\dist" -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -G"NMake Makefiles"
cd build
nmake
nmake test
nmake check
nmake install
nmake clean
nmake test builds the test executable; nmake check runs it. Installation uses the prefix recorded during CMake configuration.
The MSVC environment preparation below is shared by the CMake/Ninja, CMake-Presets, Meson, and CMake/NMake workflows. Complete it once in the shell that will be used for the build, then remain in that initialized shell while running the commands from the relevant workflow section above.
MSVC tools are not normally available in an ordinary Command Prompt until the Visual Studio compiler environment has been initialized. Open the Windows Start menu, locate the installed Visual Studio folder, and choose a developer shell matching the architecture you intend to build.
Native Tools Command Prompt
x86 Native Tools Command Prompt
x64 Native Tools Command Prompt
Developer Command Prompt for Visual Studio
x86 Native Tools Command Prompt for Visual Studio
x64 Native Tools Command Prompt for Visual Studio
Developer PowerShell for Visual Studio
If a shortcut is unavailable, the corresponding Visual Studio environment batch file can be invoked manually. The following paths are examples for Visual Studio 2022 Enterprise and must match the installed edition and location:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars32.bat"
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
cl
If the compiler is available, it will print its version and then display a usage error because no input source file was specified. This behavior is expected and confirms that cl.exe is available in the current shell.
After this one-time preparation, continue with the CMake/Ninja, CMake-Presets, Meson, or NMake commands in the corresponding workflow section above.