<div dir="ltr">uname is implemented in terms of uname(), which is what the<br>llvm::host::osName() and llvm::host:::osVersion() functions I<br>added are querying. However, the plan is to replace those with<br>one function which just constructs the target triple of the host.<br>
<br>Will such a function suffice for doing the right thing on FreeBSD?<br><br> - Daniel<br><br><div class="gmail_quote">On Fri, Oct 10, 2008 at 8:17 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">bringing back to the mailing list<br>
<br>
Begin forwarded message:<br>
<br>
> From: Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>><br>
> Date: October 10, 2008 8:16:59 AM PDT<br>
> To: Roman Divacky <<a href="mailto:rdivacky@freebsd.org">rdivacky@freebsd.org</a>><br>
> Subject: Re: [cfe-dev] [PATCH]: add support for FreeBSD<br>
<div class="Ih2E3d">><br>
>>> I think that wrapping the configuration logic with #ifdef<br>
>>> __freebsd__<br>
>>> (or whatever is appropriate) would make sense.  Follow the lead of<br>
>>> the<br>
>>> similar darwin code.<br>
>><br>
</div>>> thats not the problem :) the problem is that the given header file<br>
>> does not have to be present on the machine we are building at.<br>
>><br>
>> it's an internal freebsd sources header file.<br>
><br>
> Ah ok, that won't work then.<br>
<div class="Ih2E3d">><br>
>><br>
>><br>
>>>> I might ignite a discussion on the fbsd mailing list if we can<br>
>>>> change<br>
>>>> the sources to export these two numbers to be exported in some<br>
>>>> header file.<br>
>>><br>
>>> On darwin, we autodetect using the "approved system interfaces".<br>
>>> The<br>
>>> idea is that we want to be able to build a binary on darwin9 and<br>
>>> have<br>
>>> it run find on darwin10.  The idea is that we want the compiler to<br>
>>> default to generating code for the current OS, but that requires<br>
>>> detecting it (since the build may have been done on a different<br>
>>> one).<br>
>>><br>
>>> Make sense?<br>
>><br>
</div>>> well.. I could parse output of "touch dummy_file.c ; gcc -E -dM<br>
>> dummy_file.c"<br>
>> to get the two defines. there's no other way to get this on<br>
>> runtime, is<br>
>> this an acceptable solution?<br>
><br>
> I'm confused about why that would be useful.  Worst case you could<br>
> parse the output of 'system("uname -a")' or something, no?<br>
> Presumably uname is implemented in terms of some library/system<br>
> call, and that could just be used instead?<br>
<div><div></div><div class="Wj3C7c">><br>
> -Chris<br>
><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>