search for: toolssupport

...a dumping ground for stuff that just doesn’t fit anywhere else. > > Based on your feedback and Chandler’s maybe this just isn’t the right separation. I can look into a solution to address our hackiness without creating a separate library. > > What other stuff do you think belongs in ToolsSupport that doesn't belong in Support? Looking back at the initial email, you have command line parsing and ToolOutputFile. > > We could split out command line parsing, but it doesn't seem worth it, given that we're still carrying regex support, Unicode conversion, dynamic library suppo...

...LLVM today, that make sense for tools like llc, opt, clang, but they aren't relevant for embedded uses like LLVM in the JavaScript JIT. One example of this type of functionality is the signal handlers. I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport library. My initial candidates for the new library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually command line parsing— once it can be factored out). The primary goal of this is to make it easy for uses of LLVM that...

...uld be for us to move the nasty Mac-specific hack out of the cpp file and into a header that tools could optionally include. > > Is there some way we can prevent this Mac-specific hack from affecting our library organization? It's not clear to me that the distinction between Support and ToolsSupport is really worth it. > > Most LLVM tools are single threaded and don't need to redirect signals to the current thread. I think it's only the crash recovery logic that needs the signal to be delivered to the current thread. Maybe we should factor out a CrashRecovery library, given that...

..., that make sense for tools like llc, opt, clang, but they aren't relevant for embedded uses like LLVM in the JavaScript JIT. One example of this type of functionality is the signal handlers. > > I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport library. My initial candidates for the new library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually command line parsing— once it can be factored out). > > The primary goal of this is to make it easy for uses of...

...d have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder. Just my 2 cents. > On Nov 6, 2014, at 2:12 PM, Chris Bieneman <beanz at apple.com> wrote: > > So, I decided to try and start small. My idea here was create a ToolsSupport library, and move one small, but important function into the new library to shake out all the places that would need updating. The function I chose to start with was llvm::sys::PrintStackTraceOnErrorSignal. > > Turns out this wasn’t so small. These patches aren’t done yet, but since they’re...

...lc, opt, clang, but they aren't relevant for embedded uses like >> LLVM in the JavaScript JIT. One example of this type of functionality is >> the signal handlers. >> >> I'd like to propose migrating content that is specifically designed for >> tools into a new ToolsSupport library. My initial candidates for the new >> library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any >> functionality specific to tools (i.e. ToolOutputFile and eventually command >> line parsing— once it can be factored out). >> >> The primary goal of t...

...e for tools like llc, opt, clang, but they aren't relevant for embedded uses like LLVM in the JavaScript JIT. One example of this type of functionality is the signal handlers. >>> >>> I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport library. My initial candidates for the new library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually command line parsing— once it can be factored out). >>> >>> The primary goal of this is to make it...

...ics. For example, whether or not the regex or YAML code belongs in Support doesn't seem worth worrying too much about, because they are very isolated, don't introduce extra dependencies, and won't be linked by projects that don't use them. 3. I also see a good argument for having a ToolsSupport library, as a place for all of the very-LLVM(the compiler) specific functionality that would have no place in a shared Support library (for any number of reasons: lack of generality, invasiveness, or because they add substantial other dependencies). - Daniel On Thu, Nov 6, 2014 at 6:53 PM, Pete...