[Lldb-commits] MSVC12 support

Greg Clayton gclayton at apple.com
Wed Aug 28 13:02:26 PDT 2013


Yes in general to abstract ourselves from the system on which we are compiling:

1 - First try and use LLVM functionality where it makes sense
2 - Use LLDB Host layer
3 - Use #ifdef in .cpp files only if possible
4 - Use $ifdef in .h files as a last resort.

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.

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...

Greg

On Aug 28, 2013, at 9:35 AM, Virgile Bello <virgile.bello at gmail.com> wrote:

> 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...).
> 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?
> 
> 
> On Thu, Aug 29, 2013 at 1:07 AM, João Matos <ripzonetriton at gmail.com> wrote:
> +#ifdef _MSC_VER
> +        InterlockedIncrement(&m_last_revision);
> +#else
>          __sync_add_and_fetch(&m_last_revision, +1);
> +#endif
> 
> 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).
> 
> 
> -- 
> João Matos
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits





More information about the lldb-commits mailing list