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

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

> contains most of them. If they're non-trivial (like the ones I needed
to
> add for OSX functionality) that's a different story.
FWIW the difference is even more significant on, e.g. mingw32 because
process spawning is pretty much expensive and sometimes configure time
dominates the compile time :)


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Jan 5, 2011, at 10:31 AM, Anton Korobeynikov wrote:
>> contains most of them. If they're non-trivial (like the ones I
needed to
>> add for OSX functionality) that's a different story.
> FWIW the difference is even more significant on, e.g. mingw32 because
> process spawning is pretty much expensive and sometimes configure time
> dominates the compile time :)
Totally. It was remembering cygwin compiles that came to mind :)

-eric

Anton Korobeynikov <anton at korobeynikov.info> writes:
>> contains most of them. If they're non-trivial (like the ones I
needed to
>> add for OSX functionality) that's a different story.
> FWIW the difference is even more significant on, e.g. mingw32 because
> process spawning is pretty much expensive and sometimes configure time
> dominates the compile time :)
Yes, the time taken by configure tests (both by the `configure' script
and cmake) is annoyingly long.

Although I don't think it is the most pressing issue, if there is an
interest on it I'm not opposed to patches that remove unused platform
tests from the cmake build *and* from the autoconf build (as I don't
know about the autoconf build, someone familiar with it would need to
approve that part of the patches.)

Op 5 jan. 2011 19:33 schreef "Anton Korobeynikov" <anton at
korobeynikov.info>
het volgende:
>
> > contains most of them. If they're non-trivial (like the ones I
needed to
> > add for OSX functionality) that's a different story.
> FWIW the difference is even more significant on, e.g. mingw32 because
> process spawning is pretty much expensive and sometimes configure time
> dominates the compile time :)
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...

Ruben
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110105/a34f14ae/attachment.html>