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

>
> We may just not use those functions anymore - do you have a list of these?
>
Yes, i've started to make up a list of those functions, but it haven't
finished yet.

> This is more concerning - maybe it's a windows specific problem that
came
> along?
>
Not sure, i haven't look yet for CMake checking code itself. By the way,
i'm
using FreeBSD.

Or to say it with other words: patches welcome.
>
So, how should i proceed? Make CMake-generated config to be identical to
autotools one? Or cleanup both headers from unused stuff by Eric's
suggestion?
The latter seems more complex to me, since i see no other way except
grep'ing all code for #define's and remove those, which aren't used
anywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110105/c460a906/attachment.html>

arrowdodger <6yearold at gmail.com> writes:
>> Or to say it with other words: patches welcome.
>
> So, how should i proceed? Make CMake-generated config to be identical to
> autotools one?
That would be a good thing.

Please note that some checks are a bit tricky. A function that on
platform A is on header foo.h on another platform may be on
bar.h. Furthermore, cmake's platform testing support is not so mature as
autoconf's (at least on Unix).
> Or cleanup both headers from unused stuff by Eric's
> suggestion?
I'm not sure this is a good idea (not that it is bad either). Murphy's
Law says that a function that you remove today will be used tomorrow.

[snip]

On Jan 5, 2011, at 6:34 AM, Óscar Fuentes wrote:
> arrowdodger <6yearold at gmail.com> writes:
> 
>>> Or to say it with other words: patches welcome.
>> 
>> So, how should i proceed? Make CMake-generated config to be identical
to
>> autotools one?
> 
> That would be a good thing.
> 
> Please note that some checks are a bit tricky. A function that on
> platform A is on header foo.h on another platform may be on
> bar.h. Furthermore, cmake's platform testing support is not so mature
as
> autoconf's (at least on Unix).
> 
>> Or cleanup both headers from unused stuff by Eric's
>> suggestion?
> 
> I'm not sure this is a good idea (not that it is bad either).
Murphy's
> Law says that a function that you remove today will be used tomorrow.
I meant literally functions that aren't used in the codebase. No need to
look for them if we're not using them.

-eric