Avro
  1. Avro
  2. AVRO-374

After a fresh 'build.sh test' svn reports certain files modified in Ubuntu 9.10

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3.0
    • Component/s: c++
    • Labels:
      None

      Description

      After fresh checkout and a "build.sh test", svn says certain C++ related files as modified:

      M       lang/c++/configure
      M       lang/c++/Makefile.in
      M       lang/c++/config/depcomp
      M       lang/c++/config/missing
      M       lang/c++/config/config.guess
      M       lang/c++/config/config.sub
      M       lang/c++/config/ltmain.sh
      M       lang/c++/config/install-sh
      M       lang/c++/config/ylwrap
      M       lang/c++/INSTALL
      M       lang/c++/aclocal.m4
      

      It appears that these files are generated during the build and they are platform-dependent. If so, they should not be checked in to svn.

      1. AVRO-374.patch
        1 kB
        Scott Banachowski
      2. applypatch374.sh
        0.3 kB
        Scott Banachowski
      3. ignore374
        0.1 kB
        Scott Banachowski

        Activity

        Hide
        Thiruvalluvan M. G. added a comment -

        +1

        Verified that the patch works in both cygwin and Ubuntu 9.10.

        It'll be nice if we can make svn ignore these files:

        lang/c++/m4/ltsugar.m4
        lang/c++/m4/libtool.m4
        lang/c++/m4/ltversion.m4
        lang/c++/m4/lt~obsolete.m4
        lang/c++/m4/ltoptions.m4

        Thanks Scott.

        Show
        Thiruvalluvan M. G. added a comment - +1 Verified that the patch works in both cygwin and Ubuntu 9.10. It'll be nice if we can make svn ignore these files: lang/c++/m4/ltsugar.m4 lang/c++/m4/libtool.m4 lang/c++/m4/ltversion.m4 lang/c++/m4/lt~obsolete.m4 lang/c++/m4/ltoptions.m4 Thanks Scott.
        Hide
        Scott Banachowski added a comment -

        To apply patch, put all three files in the root directory, then run the applypatch374.sh script

        Show
        Scott Banachowski added a comment - To apply patch, put all three files in the root directory, then run the applypatch374.sh script
        Hide
        Matt Massie added a comment -

        I would advise that you only check in your Makefile.am and configure.in files. We should svn/git ignore all the autogenerated files since they will vary based on the version of autotools installed on the host building Avro C++.

        To build a distributable tarball,
        $ cd lang/c++
        $ autoreconf -f -i
        $ ./configure && make distcheck

        should do that trick. The 'distcheck' target will do a VPATH build of Avro C++ and all it's test. If all tests succeed, it will create a distributable tarball with all the files people will need to successfully build Avro C++. It would be best if we use the same machine to create the tarball or at least machines with the same version of autotools.

        Show
        Matt Massie added a comment - I would advise that you only check in your Makefile.am and configure.in files. We should svn/git ignore all the autogenerated files since they will vary based on the version of autotools installed on the host building Avro C++. To build a distributable tarball, $ cd lang/c++ $ autoreconf -f -i $ ./configure && make distcheck should do that trick. The 'distcheck' target will do a VPATH build of Avro C++ and all it's test. If all tests succeed, it will create a distributable tarball with all the files people will need to successfully build Avro C++. It would be best if we use the same machine to create the tarball or at least machines with the same version of autotools.
        Hide
        Scott Banachowski added a comment -

        Typically, a user should be able to start with configure, and so those files are usually bundled in a distribution package. Only a maintainer should have to run a command to generate those files. If we take the view that a top-level avro build is a done by a maintainer, then leaving those files out of the repository seems reasonable. Otherwise I'd prefer to package them.

        Matt knows more about the autotools chain than I. Perhaps he can advise here.

        Show
        Scott Banachowski added a comment - Typically, a user should be able to start with configure, and so those files are usually bundled in a distribution package. Only a maintainer should have to run a command to generate those files. If we take the view that a top-level avro build is a done by a maintainer, then leaving those files out of the repository seems reasonable. Otherwise I'd prefer to package them. Matt knows more about the autotools chain than I. Perhaps he can advise here.
        Hide
        Thiruvalluvan M. G. added a comment -

        Maybe I'm missing something. If autoreconf is going to always generate (or copy) these files, can we not drop them from svn?

        Show
        Thiruvalluvan M. G. added a comment - Maybe I'm missing something. If autoreconf is going to always generate (or copy) these files, can we not drop them from svn?
        Hide
        Scott Banachowski added a comment -

        Hmm, as I suspected the warnings cannot be ignored, as the build fails on cygwin without the autoreconf step (it spits out errors about incompatible autoconf).

        If modifying those files is really a problem, what I can try is to let the build.sh script run configure + make, and if it fails, then try autoreconf + configure + make. This way, it would only effect a subset of people.

        Another way would be to copy the whole source tree to build, and then only modify the copy.

        Maybe the latter is the preferred approach?

        Show
        Scott Banachowski added a comment - Hmm, as I suspected the warnings cannot be ignored, as the build fails on cygwin without the autoreconf step (it spits out errors about incompatible autoconf). If modifying those files is really a problem, what I can try is to let the build.sh script run configure + make, and if it fails, then try autoreconf + configure + make. This way, it would only effect a subset of people. Another way would be to copy the whole source tree to build, and then only modify the copy. Maybe the latter is the preferred approach?
        Hide
        Scott Banachowski added a comment -

        Hi Thiru, this is because build.sh is running autoreconf, If your version of autotools is different version than mine, it ends up copying the files from yours into the build directory so the build works.

        I think I added this to get around warnings that were being issued by the configure script when run on machines with different versions of autotools. If these warnings don't really break the build, I suppose we can skip running autoreconf and just run configure.

        I'll patch that shortly.

        Show
        Scott Banachowski added a comment - Hi Thiru, this is because build.sh is running autoreconf, If your version of autotools is different version than mine, it ends up copying the files from yours into the build directory so the build works. I think I added this to get around warnings that were being issued by the configure script when run on machines with different versions of autotools. If these warnings don't really break the build, I suppose we can skip running autoreconf and just run configure. I'll patch that shortly.

          People

          • Assignee:
            Scott Banachowski
            Reporter:
            Thiruvalluvan M. G.
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development