llvm-project/lldb/source/Plugins/Language/CMakeLists.txt

add_subdirectory(CPlusPlus)
add_subdirectory(Go)
add_subdirectory(Java)
add_subdirectory(ObjC)
add_subdirectory(ObjCPlusPlus)
Add a new type of plugin: Language plugin The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212 2015-08-28 05:33:50 +08:00			`add_subdirectory(CPlusPlus)`
Add go data formatters. Differential Revision: http://reviews.llvm.org/D13878 llvm-svn: 252109 2015-11-05 08:24:36 +08:00			`add_subdirectory(Go)`
Add a set of new plugins to handle Java debugging The purpose of these plugins is to make LLDB capable of debugging java code JIT-ed by the android runtime. Differential revision: http://reviews.llvm.org/D17616 llvm-svn: 262015 2016-02-26 22:21:23 +08:00			`add_subdirectory(Java)`
Add a new type of plugin: Language plugin The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212 2015-08-28 05:33:50 +08:00			`add_subdirectory(ObjC)`
Add support for language plugins to provide data formatters (second attempt) Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568 2015-09-02 02:22:39 +08:00			`add_subdirectory(ObjCPlusPlus)`