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

[Ruben Van Boxem]

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