labath added a comment. In https://reviews.llvm.org/D26190#585106, @mehdi_amini wrote:
> >> , but LLVM is not robust to mix and match build settings: building half of > >> the source with -DNDEBUG and not the other is likely to cause weird > >> runtime failures. That can be an issue because now you need libLLDB built > >> in two modes and the client app to link the right one. > > > > I don't see how this applies. This is true when you build liblldb, and it's > > true that lldb's assertion settings need to match llvm's, but since > > liblldb's api is stable wrt. N/_DEBUG, it's user should not need to care > > about that. > > It applies at the moment you consider that the client code does not need to > link to LLVM because LLDB provides a copy. It means that now, even if it is > not relevant for the LLVM interface, the client code needs to be built with > the same configuration as the libLLDB shared lib. > > Not exposing LLVM but only the minimal non-LLVM API prevents the client code > from using any LLVM symbol from libLLDB, and thus makes it possible to > mix-n-match a release build of libLLDB with an assert built client code. > > Make sense? Ok, so you were pointing out a flaw in the first proposal, not this one. I think that's the part I missed. Yes, If we exported the llvm interface, the user could not use a different version of llvm elsewhere in the program. The thing is, the user is not supposed to do that anyway, as it violates the One Definition Rule of c++: §4: Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. [...] §6: There can be more than one definition of a class type (Clause 9), enumeration type (7.2), [list of other kinds of entities] in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements. Given such an entity named D defined in more than one translation unit, then: - each definition of D shall consist of the same sequence of tokens; and - [...] The last part fails as soon as mix different NDEBUG versions. We can make that work by not exporting the llvm interface, but then it's not really C++. :) And it can break in case you don't know what you are doing (occasionally you see people statically linking the standard c++ library into a part of their project and then marveling at the results). This is why I wanted to propose both, although at this point I think I have convinced myself as well than the first one wasn't a good idea. >> I think you'll have to repeat your point, as now I am totally confused about >> what you are trying to say. :) > > Sorry, I hope it is more clear now? Thanks. :) https://reviews.llvm.org/D26190 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
