[LLVMdev] include/Config/config.h discrepancies between CMake and autofoo builds

Ruben Van Boxem
Wed, 05 Jan 2011 21:10:29 -0000

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>:
> Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:
>
>> Yeah that's the two different ones I mean. Everything MS
(intrinsics,
>> language features etc...) is purely version-bound, so I don't even
get
>> why CMake insists on checking every known function prototype of for
>> example "recv" and for the presence of headers it (or the
project
>> dev!) should know are not there.
>
> The fact that a given function is present on one version of VC++/MinGW
> does not mean that it is present on another future or past version. The
> same could be said for the Unix case. Hard-coding that information
> defeats the purpose of platform checks.

Well, that's the strong point in the Windows API, backwards
compatibility is almost infinite! Unix, well, that seems to be a
completely different story :s...

>
> We could hard-code some check results with
>
> if( NOT WIN32 )
>  checks
> elseif( MINGW )
>  hard_coded_results_mingw
> else
>  hard_coded_results_vc
> endif()
>
> but that adds noise and increases fragility and maintenance effort. For
> just saving two or three minutes while configuring, something that most
> people don't do often (except if you are one of the build maintainers,
> of course ;-)
>
>> As for 3rdparty libraries: provide an option like autotools (about the
>> only thing (sometimes) done right)
"--with-3rdpartylibname=somePath".
>> Leave it to the user/builder to get their setup right and provide the
>> correct library (location)
>
> This is not so easy. The user can replace anything you can imagine
> of. From the compiler itself to core OS functionality. IIRC there are
> cases of people using a third-party C standard library implementation.
>
> [snip]
>

I may be naive, but shouldn't a *standard* C library implementation
use *standard* headers/function prototypes? I understand OSes like BSD
and Solaris really suck on this point (standards compliance), but I
would think linux, Mac OS and Windows at least adhere to a large
denominator which would make these checks kind of superfluous. Heck,
all of Qt builds without any of these, and it uses only a platform
specific header with the necessary defines. I would think a library
like Qt touches most dark corners of all the platforms it supports?
(not trying to be a brute here, I'm just frustrated with
Windows+autotools... and all the projects using that).

Ruben