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

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

Eric Christopher <echristo at apple.com> writes:
>>> 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.
Sorry, bad wording. What I'm trying to say is that if you remove a
function check just because it is not used by the codebase today maybe
some programmer will need that function tomorrow. And adding an autoconf
check is far from trivial, at least for those not familiarized with the
autotools.

IMHO removing configure checks because they are not used by the codebase
right now is not an improvement similar to removing dead code from the
C++ sources.

On Jan 5, 2011, at 9:58 AM, Óscar Fuentes wrote:
> Eric Christopher <echristo at apple.com> writes:
> 
>>>> 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.
> 
> Sorry, bad wording. What I'm trying to say is that if you remove a
> function check just because it is not used by the codebase today maybe
> some programmer will need that function tomorrow. And adding an autoconf
> check is far from trivial, at least for those not familiarized with the
> autotools.
> 
Adding a check for most standard functions is amazingly trivial:

AC_CHECK_FUNCS([backtrace ceilf floorf roundf rintf nearbyintf getcwd ])
AC_CHECK_FUNCS([powf fmodf strtof round ])
AC_CHECK_FUNCS([getpagesize getrusage getrlimit setrlimit gettimeofday ])
AC_CHECK_FUNCS([isatty mkdtemp mkstemp ])
AC_CHECK_FUNCS([mktemp posix_spawn realpath sbrk setrlimit strdup ])
AC_CHECK_FUNCS([strerror strerror_r strerror_s setenv ])
AC_CHECK_FUNCS([strtoll strtoq sysconf malloc_zone_statistics ])
AC_CHECK_FUNCS([setjmp longjmp sigsetjmp siglongjmp])

contains most of them. If they're non-trivial (like the ones I needed to
add for OSX functionality) that's a different story.
> IMHO removing configure checks because they are not used by the codebase
> right now is not an improvement similar to removing dead code from the
> C++ sources.
I disagree.

-eric