[Question] Allow the compile time switches to be optional or runtime switches?
- Dominant language
- C++
- Stars
- 1.9k
- Forks
- 280
- Avg merge
- 7m
- Merged PRs (30d)
- 4
Description
First and foremost, thanks for loguru, awesome library!
I have the long term plan to package loguru and get it included into openSUSE, to be able to package [cquery](https://github.com/cquery-project/cquery). Unfortunately I am facing a practical problem: nearly every linux distribution requires that libraries cannot be included as source only and have to be built as shared libraries.
Now, loguru offers a lot of compile time switches, which make a distribution as a shared library inconvenient. Most of these are probably unproblematic, as they only add features, but for instance `LOGURU_USE_FMTLIB` changes the libraries behavior. `LOGURU_WITH_FILEABS` and `LOGURU_UNSAFE_SIGNAL_HANDLER` are probably problematic too, but I haven't checked in detail.
Would you consider the option to convert some of these preprocessor `#defines` to runtime switches? E.g. `LOGURU_UNSAFE_SIGNAL_HANDLER` should be resolvable at runtime without a large performance hit. `LOGURU_USE_FMTLIB` could be maybe removed by exploiting some form of function overloading.
This would ease packaging for Linux distributions tremendously.
Contributor guide
No contributing guide indexed for this repository
Research direction
No source files, tests, or entry points are identified in the issue. Start by reviewing the named compile-time switches—LOGURU_USE_FMTLIB, LOGURU_WITH_FILEABS, and LOGURU_UNSAFE_SIGNAL_HANDLER—and the library's shared-library packaging requirements; done would be a settled design for which switches, if any, should become runtime options.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100