llvm dev - Jan 2011 - [LLVMdev] include/Config/config.h discrepancies between CMake and autofoo builds

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>:
> Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:
>
>> And this is why I don't understand configure checks for windows...
There's
>> only one/two header/library sets... The Windows SDK and MinGW. This
info
>> should be built in IMHO...
>
> Although the panorama is not so diverse as the Unix world, there is
> quite a bit of variation on Windows too. Apart from the
> cygwin/mingw/vc++ distinction, there are multiple versions of their
> respective C libraries, intrinsics and language features supported by
> the compilers, etc. Plus some people may want to use third party
> libraries for certain things.
>
> Note: the platform tests makes no difference among the official Windows
> SDK libraries and MinGW's Winapi. Maybe you are thinking on the MS C
> runtime (that evolves with every VC++ compiler release) and the MinGW C
> runtime (which wraps some version of the MS C runtime and adds stuff of
> its own.)
>
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.

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)

Sorry for the somewhat off-topic ramble :s.

Ruben

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.

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]

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