Problem with "make check"

Matt Beard
  • Matt Beard

    Matt Beard - 2004-11-05

    Original post by stuart_hc, moved from the "lock" thread.

    The "make check" target on the Develop-EssenceRead branch hangs (under Linux and WIN32) when it gets to the mxfsplit test. Do you have a fix for this? If not, I can look into it.

    • Matt Beard

      Matt Beard - 2004-11-05

      Please do look into this.


    • Stuart Cunningham

      The cause of the hang is mxfsplit's use of getchar() where it attempts to read input from the terminal.  When running under the autotest framework of "make check" it will never receive terminal input.

      The getchar() calls were removed from mxfsplit for the large portability fixes which went into mxflib-alpha-0.4.0, but were reinstated by terabrit shortly after the last release.  Not only is there no portable way to test a program reading from the terminal, the getchar() function also causes compile failures on other platforms.

      I'm reluctant to check in a fix for this if the offending code is going to be promptly reinstated.

      • Oliver Morgan

        Oliver Morgan - 2004-11-05

        I don't mind changes in operational or functional behaviour that are:
        (a) discussed beforehand
        (b) isolated from other changes by placing them in separate checkins
        (c) documented by explicit checkin comments.

      • Matt Beard

        Matt Beard - 2004-11-06

        My understanding is that getchar() is standard C++ (or at least C++ compatible C) - indeed Stroustrup suggests its use in "The C++ Programming Language" and it doesn't get much more pukka than that!!

        Command-line option "-q" will set mxfstrip into quiet mode and prevent any calls to getchar()

        I will attempt to add "-q" for make check.

        • Stuart Cunningham

          getchar() is ISO C and C++ (and IEEE 1003.1 & POSIX by reference).  Alas, not all compilers adhere to the standards.

          The 2nd mxfsplit test was intended to test verbose output of mxfsplit so that regressions would be caught.  If -q is used, only a few lines are output.  If we keep the getchar() reading from terminal behaviour for default args, we would need another flag to turn off the read-from-terminal behaviour.  Or, we could simply drop the read-from-terminal behaviour - I cannot see what benefit it provides since it occurs immediately before program exit.


Log in to post a comment.