BIND 10 #3107: [kean] ./configure report versions of dependencies

[BIND 10 Development]

#3107: [kean] ./configure report versions of dependencies
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:  kean
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  build system  |                    Milestone:
            Keywords:                |  Sprint-20130917
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  5             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => kean


Comment:

 Hi Kean

 Replying to [comment:11 kean]:
 > Re your first point (C++ compiler version). That is very difficult
 > because there is no standard. We can start building in a matrix of
 > known C++ compilers and how to extract that information but at best it
 > will be a half-baked effort because we simply don't know all of the
 > compilers people use, or what the required flags are to even get the
 > compiler version information (and some old compilers don't even have
 > the option at all). So since we can't do it for every compiler do we
 > really want to do it for only some? We can of course get 90% of the
 > target audience by simply checking to see if the compiler is gcc and
 > then using --version but that does seem a bit hokey.

 We only have to print versions for the compilers we support: GCC,
 clang++ and SunStudio. If we can detect that one of these is in use, we
 should print its version if possible, or else we can print "Unknown".

 The purpose of this bug is so we (developers) have all the information
 required when debugging a problem, especially in our builders which are
 the main source of problem reports. The compiler family and its version
 are information we look for when solving C++ and Boost interop issues.

 It seems that g++ version is already a part of `config.log`, so we're
 almost there. Please check if the similar version info is included in
 `config.log` for clang++ and SunStudio too.

 > sed on many OSes, being a key OS utility, has no version. I cannot
 > even begin to imagine why we would care about the version of sed or
 > how it qualifies as a "dependency". sed is sed - its just part of UNIX
 > :)

 There are incompatibilities among implementations of sed. This team
 fixed several issues in the last year due to such incompatibilities.
 Mainly we'd want to know if GNU sed is in use on non-Linux platforms.

 > Yes, the cpp mechanism will work for non-standard locations of
 > log4cplus.

 I'm sorry, I think I did not state it clearly. I asked that question
 after noticing that it cannot work. Please test your code against
 non-standard locations of dependencies where you run cpp.

 > As for using angle brackets, the coding guidelines apply to actual
 > source code, not to configure scripts, surely? There is good reason to
 > use quotes in configure scripts, where the ordering of -I options is
 > far more critical during feature detection.

 Please state in unambiguous terms with an example what these reasons are
 at the place where this test program is processed (after log4cplus
 INCLUDES and LIBS are determined), and why you'd want one style of
 `#include` in `configure.ac` and another in C++ source code in this case.

 > Using compiled programs versus sed is very much against autoconf
 > best-practices. It completely eliminates and alienates the
 > cross-compiler world and there is absolutely no need for it.

 There are already programs that we compile and run in `configure` to
 check for features and bugs. But I'll not insist on this point as your
 implementation prints the version numbers currently.

-- 
Ticket URL: <http://bind10.isc.org/ticket/3107#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development