<div dir="ltr">Here is an updated MSVC2013 patch with what's not merged yet. Much smaller than before!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 2:07 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looks fine to me.<br>
<div><div class="h5"><br>
On Sep 4, 2013, at 9:19 AM, Virgile Bello <<a href="mailto:virgile.bello@gmail.com">virgile.bello@gmail.com</a>> wrote:<br>
<br>
> Would such a patch be OK for getopt? (with OptionParser.h)<br>
> Didn't try to hide actual getopt architecture, but at least it prevents <getopt.h> from being included directly.<br>
><br>
> If this gets accepted, the remaining part of MSVC patch should be quite small.<br>
><br>
><br>
> On Thu, Aug 29, 2013 at 5:02 AM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> Yes in general to abstract ourselves from the system on which we are compiling:<br>
><br>
> 1 - First try and use LLVM functionality where it makes sense<br>
> 2 - Use LLDB Host layer<br>
> 3 - Use #ifdef in .cpp files only if possible<br>
> 4 - Use $ifdef in .h files as a last resort.<br>
><br>
> To get back to the "getopt.h" stuff, it would be great to make a Host class that abstracts us from the "getopt.h" functionality.<br>
><br>
> Something like "include/lldb/Host/OptionParser.h" and then a .cpp file in common that hides the abstraction for the actual unix version that is used for everything but windows, and a windows specific one that could use a compatibility layer...<br>


><br>
> Greg<br>
><br>
> On Aug 28, 2013, at 9:35 AM, Virgile Bello <<a href="mailto:virgile.bello@gmail.com">virgile.bello@gmail.com</a>> wrote:<br>
><br>
> > Ha yes sure, I thought that was not recommended since LLVM was not used for many other similar situations (i.e. Mutex, Regex, Argument parsing vs getopt, some path functions, etc...).<br>
> > But I suppose it is maybe due more to the fact it wasn't good/stable enough at the time you needed it, and switch would be OK now?<br>
> ><br>
> ><br>
> > On Thu, Aug 29, 2013 at 1:07 AM, Joćo Matos <<a href="mailto:ripzonetriton@gmail.com">ripzonetriton@gmail.com</a>> wrote:<br>
> > +#ifdef _MSC_VER<br>
> > +        InterlockedIncrement(&m_last_revision);<br>
> > +#else<br>
> >          __sync_add_and_fetch(&m_last_revision, +1);<br>
> > +#endif<br>
> ><br>
> > I see this pattern ifdef'd in a lot of places, I think we should abstract it in an helper "atomics" function, or even better, just re-use LLVM support libraries (llvm::sys::AtomicIncrement).<br>
> ><br>
> ><br>
> > --<br>
> > Joćo Matos<br>
> ><br>
> > _______________________________________________<br>
> > lldb-commits mailing list<br>
> > <a href="mailto:lldb-commits@cs.uiuc.edu">lldb-commits@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
><br>
><br>
</div></div>> <lldb-getopt.diff><br>
<br>
</blockquote></div><br></div>