On Wed, Jan 11, 2017 at 10:38 AM, Zachary Turner <ztur...@google.com> wrote:
> > > On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath <lab...@google.com> wrote: > >> Happy new year everyone. :) >> >> I have refreshed the implementation at >> <https://reviews.llvm.org/D27459> with something more polished. I >> consider this almost-ready, I just need feedback on a couple of >> details: >> >> - log->Warning/Debug/Error/Verbose: Currently we have a large number >> of printf-style logging functions, which are very rarely used (and all >> they do is prefix the log line with some string), and only one >> formatv-style. It would be easy to add LLDB_WARN, LLDB_ERR, etc. >> macros, so that these usages can be ported to the formatv-style. >> However, I am not sure whether that's really necessary. One of the >> goals of this process could be to standardize on one function. I would >> prefer to keep just one log function, but I could be easily convinced >> otherwise. For reference, these are the current approximate usages of >> the logging functions (as determined by grep) >> log->Error: 38 (mostly in ProcessWindows) >> log->Warning: 25 >> log->Debug: 10 (mostly ClangExpressionParser) >> log->Verbose: 6 (only ProcessWindows) >> log->Printf: 2884 >> > Yea, these are unnecessary and it would be great to get rid of them. > > >> >> - ProcessWindowsLog: I am not going to go on a reformatting spree to >> change all logging statements, but I would still like to change remove >> the logging macros that windows log introduced, since they are very >> custom, and I'd like to keep the number of logging syntaxes below 3 >> :). Zachary, Adrian, is that OK with you? >> > Fine with me, they were only introduced as an alternative to the verbose > if (log) syntaxes. If there's an alternative that also solves the problem > and we can adopt everywhere, then I'm all for it. > Fine with me as well. > > >> >> I must confess have a bit of an ulterior motive for doing this. :) My >> goal is to start working on the modularization of the codebase. But I >> don't want it to be just mindless moving of code around. I want to >> spend some time considering the design of each piece, which should >> slow things down long enough for the moves to not be annoying, and >> hopefully produce better components. I'll write more on that soon - I >> don't want to derail this discussion with it. >> > I'd start with one support library which we document and write in stone > (perhaps even enforce in CMake) that it can have no other dependencies on > LLDB libraries. Then start moving various common data structures and > classes over there. Like you said, we should save the details for another > thread, but in any case i look forward to seeing some proposals :) >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev