@themightyoarfish I would want to avoid depending on a logging library if possible. Adding new dependencies is always a big pain (need to check the license, need to make sure the dependency is available on all systems and in all package managers, have to be sure that the dependency will be maintained in the future, if there are bugs in the dependency we often have to deal with them (as we experienced several times with VTK)).

What do you think about the following function:

void redirect_logging (VERBOSITY_LEVEL level, FILE *stream);

Then you could for example redirect all WARNINGS to log_file.txt:

FILE* f = fopen("log_file.txt", "w");
pcl::console::redirect_logging(pcl::console::L_WARN, f);

Something like that would be helpful, yes. No full logging library needed, just a way to intercept PCL logs to redirect them into our own logging.

Hello!
Has such a feature been developed? It would be nice indeed to be able to intercept logs emitted by PCL, especially in GUI applications that use the library without any console attached.

I'm also interested in this, to forward all logs to ROS 2 logger.

@roncapat I am not so familiar with the ROS 2 logging, do you have a suggestion how to achieve forwarding? What does PCL have to offer to make that possible? Would my earlier idea (void redirect_logging (VERBOSITY_LEVEL level, FILE *stream);) work? And: why do you want to forward the logs anyway? What do you want to achieve? Does ROS not simply print to std::cout and std::cerr?

The most flexible solution would just be to be able to register a log callback (or callable, better yet), then the user can do with the info whatever they wish.

Hello!
Yes indeed being able to install a "hook" that receives the log details and let the user do what they want with it would be great / is what most libs do.
For example:

• qInstallMessageHandler for Qt
• dds_set_log_sink for CycloneDDS
• log_set_writer_func in GTK

It's more flexible than to redirect to a file:

• as a user I prefer to merge these logs with my own logs, all in the same file
• it also works better when wrapping the lib (to make it callable from Python for example)

Yes I agree that a generic callback with a sound signature, passing like at least the PCL log level and a message string would be nice, allowing flexibility.

Draft example:

auto cb = [](VERBOSITY_LEVEL level, const std::string & message) -> void {
  // do something with the string, maybe considering (or not) the delcared PCL log level. 
};

pcl::console::redirect_logging(&cb);

And have the ability to pass in some user data, either via a void* pointer argument, or by being able to register any callable. Otherwise the user will be forced to use global logging, without ability to separate logs based on which object/module spawned them.

Yes. You may consider extra 2 points:

• give access / return the previous callback (the default handler basically) so it can be restored later on, or be "decorated" by the new one
• passing all log details via a single struct rather than multiples arguments to not break the user code the day you want to add a new field

And as suggested by @themightyoarfish accepting a std::function rather than a C function pointer would allow the users to capture the custom data they need in a lambda in an elegant way rather than relying on an void * arg

struct LogRecord
{
    VERBOSITY_LEVEL level;
    std::string_view message;
};
auto cb = [mylogger](const LogRecord & r) {
     mylogger->log(r.level, r.message);
};

pcl::console::redirect_logging(&cb);

For your information: pull request #6244 Comments and suggestions welcome