Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow more user control over logging #110

Closed
kyllingstad opened this issue Dec 5, 2018 · 1 comment
Closed

Allow more user control over logging #110

kyllingstad opened this issue Dec 5, 2018 · 1 comment
Assignees
@kyllingstad
Labels
enhancement New feature or request

Comments

@kyllingstad
Copy link
Member

To give client code greater control over logging, a few more items should be added to the public API in cse/log.hpp:

  • A way to retrieve the default logger (already in the private API, in cse/log/logger.hpp, but may have to be modified a bit)
  • A way to retrieve and modify the default log sink
@kyllingstad kyllingstad added the enhancement New feature or request label Dec 5, 2018
@kyllingstad kyllingstad self-assigned this Dec 5, 2018
@kyllingstad kyllingstad removed their assignment May 31, 2019
@kyllingstad kyllingstad self-assigned this Jul 29, 2019
@kyllingstad kyllingstad mentioned this issue Jul 29, 2019
Closed
2 tasks
kyllingstad added a commit that referenced this issue Jul 29, 2019
@kyllingstad
WIP on #110, user controllable logging
28cfd60
@kyllingstad
Copy link
Member Author

Having worked on this for a bit now, I'm in a better position to say what I'd like to achieve and how to get there, so let me try to rephrase the issue.

The primary motivation is that cse-core users should be allowed to have full control over their programs' output. We should not just assume that users are happy to have messages written to the console in whichever format we decide. Furthermore, client code may already be using Boost.Log, and since the core of that library is a global singleton, we shouldn't just apply our own settings to it without the users asking for it.

Here is what I want to do:

  1. Move global settings into separate functions that users can call if they so wish. Otherwise, rely on Boost.Log default settings.
  2. Allow users access to the cse-core logger (source), so they can use it or reconfigure it as they see fit.
  3. In general, allow for better integration with other code that uses Boost.Log.

An immediate use case for all this is CSE CLI, which will have command-line switches to control logging.

kyllingstad added a commit that referenced this issue Jul 30, 2019
@kyllingstad
Give client code more control over logging
5f11f28 
This changes the logging API so that it allows client code to have more
control over logging, and to enable better integration with client code
that also uses Boost.Log.

Summary of changes:
- `cse::log::level` renamed to `severity_level` and turned into a
  pseudo-alias for `boost::log::trivial::severity_level`.
- Modification of global settings is now done by separate functions that
  users must call explicitly.  These are in a new header,
  `cse/log/simple.hpp`.
- Similar changes in the C library.
- Added setup function calls to all tests, with an output level of
  "info" if no other level was previously requested.

This closes #110.
kyllingstad added a commit that referenced this issue Jul 30, 2019
@kyllingstad
Give client code more control over logging
b9a1830 
This changes the logging API so that it allows client code to have more
control over logging, and to enable better integration with client code
that also uses Boost.Log.

Summary of changes:
- `cse::log::level` renamed to `severity_level` and turned into a
  pseudo-alias for `boost::log::trivial::severity_level`.
- Modification of global settings is now done by separate functions that
  users must call explicitly.  These are in a new header,
  `cse/log/simple.hpp`.
- Similar changes in the C library.
- Added setup function calls to all tests, with an output level of
  "info" if no other level was previously requested.

This closes #110.
@kyllingstad kyllingstad mentioned this issue Jul 30, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kyllingstad kyllingstad

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@kyllingstad