Is there any value in having an LLDB_HOST_XXX set of macros such as the following:
LLDB_HOST_APPLE LLDB_HOST_WIN32 LLDB_HOST_MINGW LLDB_HOST_LINUX LLDB_HOST_BSD The last one would translate to __FreeBSD__ || __FreeBSD_kernel__ || __OpenBSD__ || __NetBSD__ In lldb/Host/Config.h, we use the presence of any of these 4 things to include lldb/Host/freebsd/Config.h. But then in most other places, we either only check for __FreeBSD__ or only check for __FreeBSD_kernel__. Since the platforms are similar, it seems like *most of the time* you just want to check for all 4, and checking for some subset of those would be the exception. For example, in my previous HostThread refactoring changelist, I created this HostThreadFreeBSD class. That class isn't going to be compiled on OpenBSD or NetBSD though (at least on the CMake build, which I know you don't use, but still). So that seems like a bug. Do you agree that more often than not, when we check for FreeBSD we want to check for all of the BSD variants? Or am I wrong there? On Fri, Sep 12, 2014 at 10:14 AM, Ed Maste <ema...@freebsd.org> wrote: > On 12 September 2014 12:59, Zachary Turner <ztur...@google.com> wrote: > > The important thing seems to be whether glibc implies linux, not the > other > > way around. > > It doesn't -- Debian k/FreeBSD has __GLIBC__ and __FreeBSD_kernel__, > and not __linux__. > > > The issue is that all of our CMake decisions are based on OS platform. > If I > > want to conditionally compile an entire file based on one of these > > conditions, I need to translate it into something that fits well into the > > CMake build. > > That should be fine, although in some cases there won't be a mapping > to a single OS if multiple macros are used. > > An OS to macro map would include, for example: > > FreeBSD: __FreeBSD__, __FreeBSD_kernel__ > Linux distros: __linux__, __GLIBC__ > kFreeBSD: __GLIBC__, __FreeBSD_kernel__ > > The kFreeBSD project needs to use the FreeBSD kernel's debugging > interface (e.g., the ptrace syscall and constants) and glibc's > userland interfaces (e.g., setting thread names). >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
