How to share easylogging++ logger between executable and shared library?

843 views Asked by At

I have a CMake project that consists of a library sub-project and another sub-project that builds an executables and links it against that library.

Right now inside a source file of my library (currently the only place I'm logging anything) I need to use INITIALIZE_EASYLOGGINGPP (otherwise I get the typical unresolved externals linker error). Since I am loading the easylogging++ configuration from a file in my main() I also need to put a INITIALIZE_EASYLOGGINGPP there. From the documentation of easylogging++ this is correct since these are two separate translation units.

I am including both the header and source files (easylogging.cc and easylogging.h) to both targets:

Library project

include_directories(core
  ${INCLUDE_DIR}
  ${CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES}
  ${DEPS}/json/single_include
  ${DEPS}/easyloggingpp/src
)

add_library(core
SHARED
  ${SRC} # Contains my own source files for the library
  ${DEPS}/easyloggingpp/src/easylogging++.cc
)

Executable that links against the library

add_executable(playground
    ${SRC}
    ${DEPS}/easyloggingpp/src/easylogging++.cc
)
target_include_directories(playground
    PUBLIC
    ${INCLUDE_DIR}
    ${DEPS}/easyloggingpp/src
    ${DEPS}/json/single_include
)

This results in multiple log files (probably because of multiple loggers?). I am using a default configuration taken from the git repository:

* GLOBAL:
   FORMAT               =  "%datetime %msg"
   FILENAME             =  "playground.log"
   ENABLED              =  true
   TO_FILE              =  true
   TO_STANDARD_OUTPUT   =  true
   SUBSECOND_PRECISION  =  6
   PERFORMANCE_TRACKING =  true
   MAX_LOG_FILE_SIZE    =  2097152 ## 2MB - Comment starts with two hashes (##)
   LOG_FLUSH_THRESHOLD  =  100 ## Flush after every 100 logs
* DEBUG:
   FORMAT               = "%datetime{%d/%M} %func %msg"

In the binary where my executable runs I get playground.log but also myeasylog.log with the latter containing log output from my library.

--

In the code below following namespace aliases are defined in core.h for consistency purposes:

  • project::core::logging - for the el namespace (easylogging++)
  • project::core::configuration for the nlohmann namespace (JSON)

In addition I am using JSON for loading the runtime configuration of my project. Currently it contains only

{
  "logging": {
    "info": "Absolute or relative path to the easylogging++ configuration file. Refer to https://github.com/amrayn/easyloggingpp#using-configuration-file for more information",
    "configuration_file": "logging.conf"
  }
}

with logging.conf already listed above as the configuration for easylogging++.

Executable that links against the library - main.cpp

#include <core.h>
#include <iostream>

INITIALIZE_EASYLOGGINGPP

int main(int argc, char* argv[])
{

    // TODO Globally configure all loggers to use the same easylogging++ configuration file

    std::ifstream configFile("..\\projectconfig.json");
    project::core::configuration::json config;
    configFile >> config;
    project::core::logging::Configurations loggingConfig(config["logging"]["configuration_file"]);
    project::core::logging::Loggers::setDefaultConfigurations(loggingConfig, true);

    //project::core::logging::Loggers::reconfigureAllLoggers(loggingConfig);
    //std::string path = config["logging"]["configuration_file"]
    //project::core::logging::Loggers::configureFromGlobal(std::to_string());
    
    // Library related calls and data
    int devIDMaxMem = 0;
    int devIDMaxCudaVersion = 0;

    auto res = project::core::cuda::listCudaDevices(devIDMaxMem, devIDMaxCudaVersion, true);
    project::core::cuda::printCudaError(static_cast<cudaError_t>(res));

    project::core::dx::printDirect3DInfo();
    
    return 0;
}

As you can see I've tried using setDefaultConfigurations(), configureFromGlobal() and reconfigureAllLoggers() but without any success.

I am thinking of loading the configuration inside my library too (for every translation unit) but this is ugly and I am hoping wrong due to a better solution being available.

0

There are 0 answers