[lldb-dev] LLDB API c++ exports

[Zachary Turner]

Disregard the above message, I got it done with no private define as
discussed, so hopefully the patch I've uploaded is a better solution.  If
the methods and classes aren't intended to be used externally anyway, then
there's no reason to even have them be part of the public interface to
begin with, so I just made them all private.


On Tue, May 27, 2014 at 4:00 PM, Zachary Turner <zturner at google.com> wrote:

> Hmm, I see.  Complete Mac noobie here, is it possible to make these
> changes without Xcode?  I looked at lldb.xcodeproj, and it's harder to read
> than a Visual Studio .vcxproj file, so I assume this isn't intended to be
> hand-edited.
>
> Would it be sufficient to make my condition something like
>
> #if defined(LLDB_API_INTERNAL) || defined(MAC_OSX)
>
> submit it this way, and then let a mac person make the necessary changes
> to the Xcode build?
>
>
> On Tue, May 27, 2014 at 3:39 PM, Todd Fiala <tfiala at google.com> wrote:
>
>> > Does Mac OSX use the cmake build?
>>
>> Not really.  The Xcode lldb-tool build is the canonical MacOSX build.  It
>> builds with cmake but IIRC many (most?) of the tests fail with that build.
>>
>>
>> On Tue, May 27, 2014 at 2:59 PM, Zachary Turner <zturner at google.com>wrote:
>>
>>> On Tue, May 27, 2014 at 2:56 PM,  <jingham at apple.com> wrote:
>>> >
>>> >> On May 27, 2014, at 2:49 PM, Zachary Turner <zturner at google.com>
>>> wrote:
>>> >> What I meant is that you change this (for example):
>>> >>
>>> >> std::shared_ptr<ValueImpl> m_opaque_sp;
>>> >>
>>> >> to this:
>>> >>
>>> >> std::shared_ptr<ValueImpl>* m_opaque_sp;
>>> >>
>>> >> And allocate in the constructor / copy constructor, delete in the
>>> >> destructor.  Then you change every occurrence of m_opaque_sp-> to
>>> >> (*m_opaque_sp)->
>>> >>
>>> >
>>> > No, I don't think we should do that either.  It just adds ugly boiler
>>> plate and the chance for error, and doesn't solve any actual problems.
>>>
>>> Greg's suggestion will still generate the warnings (at least in MSVC),
>>> for the simple fact that the shared_ptr<> etc is declared as a
>>> stack-based class member.  But if it's guaranteed that these methods
>>> aren't publicly accessible, then suppressing the warning is probably
>>> fine.
>>>
>>> I'm a Windows person, so I don't have the means to easily test this
>>> kind of change on Mac OSX.  Does Mac OSX use the cmake build?  If so,
>>> does this mean I only need to define LLDB_PRIVATE in the cmake file
>>> and can assume it will work on the Mac build?  Or is there more
>>> involved?
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>
>>
>>
>> --
>>  Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140527/cba66627/attachment.html>