Hello. I see many discrepancies in config.h file generated by CMake and
autoheader.
Most of them are following:
In autofoo-generated config:
/* Define to 1 if you have the `<name>' function. */ #define HAVE_<name> 1
but in CMake-generated:
#undef HAVE_<name>
This happens because in config.h.cmake (config.h.in analog) these functions
just are not checked for.
Right.
Another difference:
autofoo sets this by default:
#define ENABLE_PIC 1
while CMake not.
There are many other differencies, which bother me, so here is the question:
is it harmless and if not - should i try to fix it?
AFAIK a typical autoconf setup does not start from scratch. It reuses
scripts or templates taken from some other project or from autoconf
itself. This means that lots of stuff listed on config.h is not
actually used by the LLVM C++ sources. The macro ENABLE_PIC is one
example.
config.h.cmake was derived from config.h.in and not all tests were
implemented. It would be nice to test them all, just for the sake of
coherence. Or to say it with other words: patches welcome.
Hello. I see many discrepancies in config.h file generated by CMake and autoheader.
Most of them are following:
In autofoo-generated config:
/* Define to 1 if you have the `<name>' function. */ #define HAVE_<name> 1
but in CMake-generated: #undef HAVE_<name>
This happens because in config.h.cmake (config.h.in analog) these functions just are not checked for.
We may just not use those functions anymore - do you have a list of these?
Another difference:
autofoo sets this by default: #define ENABLE_PIC 1
while CMake not.
This is more concerning - maybe it's a windows specific problem that came along?
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.
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.
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.
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:
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.
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
Anton Korobeynikov <anton@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.)
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 Van Boxem <vanboxem.ruben@gmail.com> writes:
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...
Although the panorama is not so diverse as the Unix world, there is
quite a bit of variation on Windows too. Apart from the
cygwin/mingw/vc++ distinction, there are multiple versions of their
respective C libraries, intrinsics and language features supported by
the compilers, etc. Plus some people may want to use third party
libraries for certain things.
Note: the platform tests makes no difference among the official Windows
SDK libraries and MinGW's Winapi. Maybe you are thinking on the MS C
runtime (that evolves with every VC++ compiler release) and the MinGW C
runtime (which wraps some version of the MS C runtime and adds stuff of
its own.)
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.
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)
Ruben Van Boxem <vanboxem.ruben@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.
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.
Ruben Van Boxem <vanboxem.ruben@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...
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 Van Boxem <vanboxem.ruben@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.
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.
