[cfe-dev] Fwd: [PATCH]: add support for FreeBSD

[Daniel Dunbar]

uname is implemented in terms of uname(), which is what the
llvm::host::osName() and llvm::host:::osVersion() functions I
added are querying. However, the plan is to replace those with
one function which just constructs the target triple of the host.

Will such a function suffice for doing the right thing on FreeBSD?

 - Daniel

On Fri, Oct 10, 2008 at 8:17 AM, Chris Lattner <clattner at apple.com> wrote:

> bringing back to the mailing list
>
> Begin forwarded message:
>
> > From: Chris Lattner <clattner at apple.com>
> > Date: October 10, 2008 8:16:59 AM PDT
> > To: Roman Divacky <rdivacky at freebsd.org>
> > Subject: Re: [cfe-dev] [PATCH]: add support for FreeBSD
> >
> >>> I think that wrapping the configuration logic with #ifdef
> >>> __freebsd__
> >>> (or whatever is appropriate) would make sense.  Follow the lead of
> >>> the
> >>> similar darwin code.
> >>
> >> thats not the problem :) the problem is that the given header file
> >> does not have to be present on the machine we are building at.
> >>
> >> it's an internal freebsd sources header file.
> >
> > Ah ok, that won't work then.
> >
> >>
> >>
> >>>> I might ignite a discussion on the fbsd mailing list if we can
> >>>> change
> >>>> the sources to export these two numbers to be exported in some
> >>>> header file.
> >>>
> >>> On darwin, we autodetect using the "approved system interfaces".
> >>> The
> >>> idea is that we want to be able to build a binary on darwin9 and
> >>> have
> >>> it run find on darwin10.  The idea is that we want the compiler to
> >>> default to generating code for the current OS, but that requires
> >>> detecting it (since the build may have been done on a different
> >>> one).
> >>>
> >>> Make sense?
> >>
> >> well.. I could parse output of "touch dummy_file.c ; gcc -E -dM
> >> dummy_file.c"
> >> to get the two defines. there's no other way to get this on
> >> runtime, is
> >> this an acceptable solution?
> >
> > I'm confused about why that would be useful.  Worst case you could
> > parse the output of 'system("uname -a")' or something, no?
> > Presumably uname is implemented in terms of some library/system
> > call, and that could just be used instead?
> >
> > -Chris
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20081010/c39a2318/attachment.html>