[BuildTools] The autoconf way of doing the autoconf stuff

[Matěj Týč]

Hello again,
I have some proposals regarding possible improvements (or at least I
think that they are actually improvements :-) of the build system.
First of all, all of the stuff is located in one coin.m4 file.
I would propose to split that file into multiple files like
package_checks.m4, flags_checks.m4 etc. From the practical point of
view, Subversion will be happier with multiple smaller files because of
easier conflict resolutions, and the build system will become more
transparent, too.

Next I can see that quite a lot of effort is being spent into finding
the right compiler flags.
What the Autoconf guys say quite often is "check for features, not for
version numbers/platforms/etc." 
http://old.nabble.com/Library-version-thru-autoconf---td22001656.html
http://blog.flameeyes.eu/2009/09/01/why-autoconf-updates-are-never-really-clean
(search for the "autoconf way" string)
And it is true that the coin.m4 file is quite long because you check for
platforms and for various compilers quite often. Although I believe that
this may be necessary to some point, there is a macro in "Autoconf
extra" repository
http://www.gnu.org/software/autoconf-archive/ax_check_compiler_flags.html#ax_check_compiler_flags
that checks whether a flag is usable with the current compiler (there's
one for linker, too).
So the idea of how to simplify stuff would be just to check whether a
flag generates an error or not with a particular compiler without caring
about the compiler or about the platform.
If there is a need to use a particular compiler, IMHO the user or
packager should do it because they have those really up-to-date
information and this requirement should be properly documented (I have
seen that there is some compiler prioritizing stuff going on). But we
can discuss that... 
I am as well aware that there may be cases when a certain flag is valid
for multiple compilers and means different thing every time and this
looks quite troublesome, but I think that this is quite rare and most of
the time it should be OK. 
The benefit coming from that approach include more simple and possibly
more robust setup (the guy in the blog claims so).
OK, that's for now.
Regards,
Matej