I'll make a more detailed comment next week, but while in general this looks very good (thanks!), I think the "reemitting" needs some change. Currently, this will duplicate warning/error messages, they will be once printed during the run and once after the run. My initial thought behind reemitting was that we hide the output in standalone mode, but actually that is not the case (by default at least) in Brian2CUDA. So with the new logging system, we will already see the relevant messages during the run (according to the console log level configuration), there is no need to print them again after the run. However, the messages that are printed during the run are not included in Brian's file log (which is by default deleted if everything goes well, actually). I need to think a bit more about this, but a failing simulation is probably the main use case where we'd like to reemit log messages, but we'd only send them to the file handler. Another option would be to directly print things to the file log from within the C++ code, i.e. to also take the file log level into account. Maybe this is actually the easiest solution, and also the more robust. For example, if a simulation crashes completely, there might still be helpful stuff in the log, even if we never get back to Python to reemit things.

A few more notes, but no need to rush this:

• I think the log messages should go to stderr, for consistency with the Python logging
• As briefly mentioned above, ideally we would write to the standard log file during the run (as configured by the file log level). However, this is not as straightforward as it sounds, since in Python we use a rotating log, and I don't think this would work well with someone else writing to the log file, i.e. code bypassing the Python log system. Also, especially on Windows we might not even be able to write to the file if its handle is opened by Python? So the separate file and the reemitting (but only to the FileHandler) in the end is probably still the best solution.
• As I mentioned earlier, we actually delete the log file after a successful run (at least by default), the main use case of a log file is therefore for failed runs and for debugging. We should think about common errors one could get and whether they end up in the log file with the current solution. The most relevant is probably an out of memory error (i.e. a failing cudaMalloc) – with this PR, those would go through B2C_LOG_ERROR, right?

Thank you @mstimberg , that makes sense. I’ll switch host logging to stderr and keep the separate CUDA log file, re-emitting it only to the FileHandler. so that we can avoid duplicated console output but still record relevant messages when failures happen. For OOM/cudaMalloc failures, yes, they go through B2C_LOG_ERRORvia CUDA_SAFE_CALL / _cudaSafeCall and will be captured after a failed run.