llvm dev - Jan 2011 - [LLVMdev] Fw: 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:
>
>> 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

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes:
> 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...
Don't confuse the Windows API with the C standard library. As mentioned
before, there are no tests for Windows API stuff on the LLVM cmake
build.
> I may be naive, but shouldn't a *standard* C library implementation
> use *standard* headers/function prototypes?
Yes, they should :-)
> 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.
Precisely, VC++ "standard" C library is full of surprises. They add
some
with every release.

[snip]

Whoops, phone rang and I forgot to cc to the list before I typed the message.


----- Forwarded Message ----
> From: Samuel Crow <samuraileumas at yahoo.com>
> To: Ruben Van Boxem <vanboxem.ruben at gmail.com>
> Sent: Wed, January 5, 2011 3:38:21 PM
> Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake
and
>autofoo builds
> 
> 
> 
> 
> 
> ----- Original Message ----
> > From: Ruben Van Boxem <vanboxem.ruben at gmail.com>
> >  To: Óscar Fuentes <ofv at wanadoo.es>
> > Cc: llvmdev at cs.uiuc.edu
> > Sent: Wed,  January 5, 2011 3:10:29 PM
> > Subject: Re: [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:
> > >
> > 
> > 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).
> > 
> 
> 
> Hi Ruben,
> 
> CMake is inspired by  QMake which is what Qt builds all of its
cross-platform
> tools with. You  might try to find a better example.
> 
> --Sam Crow
> 
> 
> 
>

Okay, i've started slowly working. Who can i send patches for review, when
they will be ready?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110106/88a7e893/attachment.html>

2011/1/5 Samuel Crow <samuraileumas at yahoo.com>:
> Whoops, phone rang and I forgot to cc to the list before I typed the
message.
>
>
> ----- Forwarded Message ----
>> From: Samuel Crow <samuraileumas at yahoo.com>
>> To: Ruben Van Boxem <vanboxem.ruben at gmail.com>
>> Sent: Wed, January 5, 2011 3:38:21 PM
>> Subject: Re: [LLVMdev] include/Config/config.h discrepancies between
CMake and
>>autofoo builds
>>
>>
>>
>>
>>
>> ----- Original Message ----
>> > From: Ruben Van Boxem <vanboxem.ruben at gmail.com>
>> >  To: Óscar Fuentes <ofv at wanadoo.es>
>> > Cc: llvmdev at cs.uiuc.edu
>> > Sent: Wed,  January 5, 2011 3:10:29 PM
>> > Subject: Re: [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:
>> > >
>> >
>> > 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).
>> >
>>
>>
>> Hi Ruben,
>>
>> CMake is inspired by  QMake which is what Qt builds all of its
cross-platform
>> tools with. You  might try to find a better example.
>>
>> --Sam Crow
>>
Well, inspiration != clone... IMHO, CMake and QMake are completely
different programs, and if there ever was resemblance, it's far gone
now. QMake uses "internal knowledge" in the form of .conf files in its
mkspecs directory, defining function aliases mostly, to make up for
platform strangeness. You'll see little difference between the msvc
"platformdefs.h" (mostly underscored function defines). Under Unix
it's still a mystery to why it's so popular and so standards ignorant
(in some variants at least).

What I propose is a QMake-like tool (with predefined
platform-toolchain combo's) with the option to pass locations of
3rd-party libraries to it. Heck, every compiler that supports it has
the option to not link to its standard (C(++)) library? (gcc:
-no-stdlib -no-startup etc...). In my ideal world ;-) the program
would not need to generate any kind of project file, but build the
whole project itself, based on a limited number of arguments passed to
it (cross-target, debug/release, 3rdparty libs). All the rest should
be self-contained in the source code itself. Your build system should
not determine whether something can be built or not, and in my eyes,
autotools lays too many constraints on the platform it's run on. Just
look at the work Mozilla needs done before it can build its software
on Windows (MSYS+patches to make it work with MSVC). CMake is only
half-way there in my eyes, and loses its fancyness when function
checks are used.

Ruben