Thread: Patch to make our build system support VPATH builds

Started: 2008-10-01 22:21:51
Last activity: 2008-10-06 21:55:51
Topics: SAC Developers
Hi, all

VPATH builds [1] are preferred by some people for the following reasons:

1. They prevent the build process form cluttering your source
directory with all sorts of build files.
2. To remove a build, all you have to do is remove the build directory.
3. You can build the same source multiple times using different
options. This is very useful if you would like to write a script that
will run the test suite for a package while the package is configured
in many different ways (e.g. different features, different compiler
optimization, and so on). It is also useful if you would like to do
the same with releasing binary distributions of the source.

Well, I think this is very desirable, since with VPATH, we can test
building from SAC's source code using different parameters, e.g.
--enable-debug, --enable-readline, --disable-editline
--disable-readline.

I made some effort to make this happen, and the patch is attached. It
is not a big patch anyways. I tested using a few different
combinations of parameters during the ./configure stage, and also in
different directories (e.g. the subdirectory of the source tree, the
parent directory of the source tree, a completely different and deep
directory elsewhere). Everything works OK for me.

[1] http://autotoolset.sourceforge.net/tutorial.html#SEC8

Explanation of what a `VPATH build' is:

In a VPATH build, the source distribution is stored in a, possibly
read-only, directory, and the actual building takes place in a
different directory where all the generated files are being
stored. We call the first directory, the source tree, and the
second directory the build tree. The build tree may be a
subdirectory of the source tree, but it is better if it is a
completely separate directory.


Best regards,

--
Kuang He
Department of Physics
University of Connecticut
Storrs, CT 06269-3046

Tel: +1.860.486.4919
Web: http://www.phys.uconn.edu/~he/

Attachments
  • George Helffrich
    2008-10-02 03:50:25
    Dear Kuang -

    VPATH is notoriously nonstandard among BSD, GNU and Sun make. Suggest
    that you validate its functioning on all those systems. If
    problematic, it might be too much hassle to make work right, despite
    being potentially attractive for simplifying maintenance.

    On 1 Oct 2008, at 20:21, Kuang He wrote:

    Hi, all

    VPATH builds [1] are preferred by some people for the following
    reasons:

    1. They prevent the build process form cluttering your source
    directory with all sorts of build files.
    2. To remove a build, all you have to do is remove the build
    directory.
    3. You can build the same source multiple times using different
    options. This is very useful if you would like to write a script that
    will run the test suite for a package while the package is configured
    in many different ways (e.g. different features, different compiler
    optimization, and so on). It is also useful if you would like to do
    the same with releasing binary distributions of the source.

    Well, I think this is very desirable, since with VPATH, we can test
    building from SAC's source code using different parameters, e.g.
    --enable-debug, --enable-readline, --disable-editline
    --disable-readline.

    I made some effort to make this happen, and the patch is attached. It
    is not a big patch anyways. I tested using a few different
    combinations of parameters during the ./configure stage, and also in
    different directories (e.g. the subdirectory of the source tree, the
    parent directory of the source tree, a completely different and deep
    directory elsewhere). Everything works OK for me.

    [1] http://autotoolset.sourceforge.net/tutorial.html#SEC8

    Explanation of what a `VPATH build' is:

    In a VPATH build, the source distribution is stored in a, possibly
    read-only, directory, and the actual building takes place in a
    different directory where all the generated files are being
    stored. We call the first directory, the source tree, and the
    second directory the build tree. The build tree may be a
    subdirectory of the source tree, but it is better if it is a
    completely separate directory.


    Best regards,

    --
    Kuang He
    Department of Physics
    University of Connecticut
    Storrs, CT 06269-3046

    Tel: +1.860.486.4919
    Web: http://www.phys.uconn.edu/~he/
    <vpath-patch.diff>_______________________________________________
    sac-dev mailing list
    sac-dev<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/sac-dev

    George Helffrich
    george<at>geology.bristol.ac.uk


    • On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich <george<at>gly.bris.ac.uk> wrote:
      VPATH is notoriously nonstandard among BSD, GNU and Sun make.
      Suggest that you validate its functioning on all those systems. If
      problematic, it might be too much hassle to make work right, despite being
      potentially attractive for simplifying maintenance.

      Dear George,

      Thanks for pointing this out. I've only tested VPATH builds using GNU
      make on linux only, and it worked. I don't have Solaris or Mac
      machines, so is there anybody who can help me test this patch on
      different operating systems other than linux (hopefully using both GNU
      make and other make programs)? Thanks!

      It is already stated in the `Readme.buildsac' file that `the build
      goes best with GNU development tools, specifically the GNU gcc and the
      GNU make'. I hope that my patch will at least work with GNU make on
      different systems. Hopefully it won't cause problem when using other
      make programs.

      I really like this feature since I can keep my source tree uncluttered
      this, and I don't need to make copies of the source tree (which is big
      and has thousands of files) at anytime.


      Best regards,

      --
      Kuang He
      Department of Physics
      University of Connecticut
      Storrs, CT 06269-3046

      Tel: +1.860.486.4919
      Web: http://www.phys.uconn.edu/~he/

      • On Wed, Oct 1, 2008 at 4:11 PM, Kuang He <icrazy<at>gmail.com> wrote:
        Dear George,

        Thanks for pointing this out. I've only tested VPATH builds using GNU
        make on linux only, and it worked. I don't have Solaris or Mac
        machines,

        A small addition: I've just tested the `VPATH build' patch on Cygwin,
        and it worked fine.

        Best regards,

        --
        Kuang He

        • Kuang,

          I will try to look at your patches this weekend. I have a all day
          meeting tomorrow.

          Patches I need to look at
          - VPATH - I will test this on the supported systems
          - PAGER - I think the solution George gave is the simplest and most
          straight forward
          If PAGER is defined use that variable, otherwise use the default sac
          paging system.
          - make distclean - Again needs to be tested on the supported systems.

          Patches which should be easy to check
          - tolower/toupper checks in build system
          - segfault on space in header variable

          Patches which look good, no changes
          - closing of the plotting window
          - CTRL-D to quit
          - sachistory string overrun

          I will keep you up to date

          Cheers
          Brian


          On Oct 1, 2008, at 7:58 PM , Kuang He wrote:

          On Wed, Oct 1, 2008 at 4:11 PM, Kuang He <icrazy<at>gmail.com> wrote:
          Dear George,

          Thanks for pointing this out. I've only tested VPATH builds using GNU
          make on linux only, and it worked. I don't have Solaris or Mac
          machines,

          A small addition: I've just tested the `VPATH build' patch on Cygwin,
          and it worked fine.

          Best regards,

          --
          Kuang He
          _______________________________________________
          sac-dev mailing list
          sac-dev<at>iris.washington.edu
          http://www.iris.washington.edu/mailman/listinfo/sac-dev


      • George Helffrich
        2008-10-05 19:51:17
        Dear All -

        I can confirm a successful vanilla build of Kuangs distribution on
        MacOS 10.3 and on FreeBSD 6.3.

        However, this build fails on a Solaris 5.7 system (due to a possibly
        unrelated problem). Perhaps Arthur can investigate further. My
        results are:

        ./configure
        checking build system type... sparc-sun-solaris2.7
        checking host system type... sparc-sun-solaris2.7
        checking target system type... sparc-sun-solaris2.7
        ...
        checking for gcc... gcc
        checking for C compiler default output file name...
        configure: error: C compiler cannot create executables
        See `config.log' for more details.
        ------------

        gcc is so old (2.7.2) that is fails configure tests using -V.

        Forcing to use Sun cc is OK until subdirectory configure is used; then
        CC gets forgotten:

        -------------
        ./configure CC=cc
        checking build system type... sparc-sun-solaris2.7
        checking host system type... sparc-sun-solaris2.7
        checking target system type... sparc-sun-solaris2.7
        ...
        configure: creating ./config.status
        config.status: creating src/Makefile
        config.status: creating utils/Makefile
        config.status: creating libedit/Makefile
        config.status: creating Makefile
        config.status: creating inc/config.h
        config.status: executing depfiles commands
        configure:

        Compliation Options for sac (Seismic Analysis Code 101.2)

        CFLAGS =
        LDFLAGS =
        LIBS = -ldl -lm -ltermcap
        Debug =
        Optimization =
        Database = off
        Matlab = off
        X11-buffer = on
        X11-depth = on
        X_LIBS = -L/usr/openwin/lib
        X_CFLAGS = -I/usr/openwin/include
        Readline = off
        Editline = on
        Install Base = /usr/local/sac
        System = sun_solaris2 (sparc-sun-solaris2.7)

        To compile sac type make
        #make
        Making all in libedit
        echo "Creating the Line Editing Library"
        Creating the Line Editing Library
        gzip -dc ./libedit-2.6.9.tar.gz | tar xvf -
        x libedit-2.6.9, 0 bytes, 0 tape blocks
        x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks
        x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks
        x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks
        ...
        (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
        INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
        creating cache ./config.cache
        checking for gcc... gcc
        checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no
        configure: error: installation or configuration problem: C compiler
        cannot create executables.
        *** Error code 1
        make: Fatal error: Command failed for target `lib/libedit.a'
        Current working directory /tmp/sac-101.2/libedit
        *** Error code 1
        make: Fatal error: Command failed for target `all-recursive'
        -----------

        Then,
        -----------
        #make CC=cc
        Making all in libedit
        (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
        INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
        loading cache ./config.cache
        checking for gcc... cc -Xc -D__EXTENSIONS__
        checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall -pipe
        -g3 ) works... no
        configure: error: installation or configuration problem: C compiler
        cannot create executables.
        *** Error code 1
        make: Fatal error: Command failed for target `lib/libedit.a'
        Current working directory /tmp/sac-101.2/libedit
        *** Error code 1
        make: Fatal error: Command failed for target `all-recursive'
        --------------

        The generated Makefiles are so exquisitely baroque as to deter any
        sensible debug effort. Suffice it to say that builds that deviate from
        a default system configuration seem unlikely to work.

        On 1 Oct 2008, at 21:11, Kuang He wrote:

        On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich
        <george<at>gly.bris.ac.uk> wrote:
        VPATH is notoriously nonstandard among BSD, GNU and Sun make.
        Suggest that you validate its functioning on all those systems. If
        problematic, it might be too much hassle to make work right, despite
        being
        potentially attractive for simplifying maintenance.

        Dear George,

        Thanks for pointing this out. I've only tested VPATH builds using GNU
        make on linux only, and it worked. I don't have Solaris or Mac
        machines, so is there anybody who can help me test this patch on
        different operating systems other than linux (hopefully using both GNU
        make and other make programs)? Thanks!

        It is already stated in the `Readme.buildsac' file that `the build
        goes best with GNU development tools, specifically the GNU gcc and the
        GNU make'. I hope that my patch will at least work with GNU make on
        different systems. Hopefully it won't cause problem when using other
        make programs.

        I really like this feature since I can keep my source tree uncluttered
        this, and I don't need to make copies of the source tree (which is big
        and has thousands of files) at anytime.


        Best regards,

        --
        Kuang He
        Department of Physics
        University of Connecticut
        Storrs, CT 06269-3046

        Tel: +1.860.486.4919
        Web: http://www.phys.uconn.edu/~he/
        _______________________________________________
        sac-dev mailing list
        sac-dev<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/sac-dev

        George Helffrich
        george<at>geology.bristol.ac.uk


        • Kuang He,

          The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir is
          not defined.
          I cannot find a resolution to this, but I will keep looking.

          I needed to rerun the bootstrap script (or autoreconf) as the
          Makefile.in files needed to be regenerated from the Makefile.am files.

          I am using autoconf 2.60 and automake 1.9.6

          Cheers
          Brian


          On Oct 5, 2008, at 7:51 AM , George Helffrich wrote:

          Dear All -

          I can confirm a successful vanilla build of Kuangs distribution on
          MacOS 10.3 and on FreeBSD 6.3.

          However, this build fails on a Solaris 5.7 system (due to a
          possibly unrelated problem). Perhaps Arthur can investigate
          further. My results are:

          ./configure
          checking build system type... sparc-sun-solaris2.7
          checking host system type... sparc-sun-solaris2.7
          checking target system type... sparc-sun-solaris2.7
          ...
          checking for gcc... gcc
          checking for C compiler default output file name...
          configure: error: C compiler cannot create executables
          See `config.log' for more details.
          ------------

          gcc is so old (2.7.2) that is fails configure tests using -V.

          Forcing to use Sun cc is OK until subdirectory configure is used;
          then CC gets forgotten:

          -------------
          ./configure CC=cc
          checking build system type... sparc-sun-solaris2.7
          checking host system type... sparc-sun-solaris2.7
          checking target system type... sparc-sun-solaris2.7
          ...
          configure: creating ./config.status
          config.status: creating src/Makefile
          config.status: creating utils/Makefile
          config.status: creating libedit/Makefile
          config.status: creating Makefile
          config.status: creating inc/config.h
          config.status: executing depfiles commands
          configure:

          Compliation Options for sac (Seismic Analysis Code 101.2)

          CFLAGS =
          LDFLAGS =
          LIBS = -ldl -lm -ltermcap
          Debug =
          Optimization =
          Database = off
          Matlab = off
          X11-buffer = on
          X11-depth = on
          X_LIBS = -L/usr/openwin/lib
          X_CFLAGS = -I/usr/openwin/include
          Readline = off
          Editline = on
          Install Base = /usr/local/sac
          System = sun_solaris2 (sparc-sun-solaris2.7)

          To compile sac type make
          #make
          Making all in libedit
          echo "Creating the Line Editing Library"
          Creating the Line Editing Library
          gzip -dc ./libedit-2.6.9.tar.gz | tar xvf -
          x libedit-2.6.9, 0 bytes, 0 tape blocks
          x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks
          x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks
          x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks
          ...
          (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
          INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
          creating cache ./config.cache
          checking for gcc... gcc
          checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no
          configure: error: installation or configuration problem: C compiler
          cannot create executables.
          *** Error code 1
          make: Fatal error: Command failed for target `lib/libedit.a'
          Current working directory /tmp/sac-101.2/libedit
          *** Error code 1
          make: Fatal error: Command failed for target `all-recursive'
          -----------

          Then,
          -----------
          #make CC=cc
          Making all in libedit
          (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
          INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
          loading cache ./config.cache
          checking for gcc... cc -Xc -D__EXTENSIONS__
          checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall -
          pipe -g3 ) works... no
          configure: error: installation or configuration problem: C compiler
          cannot create executables.
          *** Error code 1
          make: Fatal error: Command failed for target `lib/libedit.a'
          Current working directory /tmp/sac-101.2/libedit
          *** Error code 1
          make: Fatal error: Command failed for target `all-recursive'
          --------------

          The generated Makefiles are so exquisitely baroque as to deter any
          sensible debug effort. Suffice it to say that builds that deviate
          from a default system configuration seem unlikely to work.

          On 1 Oct 2008, at 21:11, Kuang He wrote:

          On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich
          <george<at>gly.bris.ac.uk> wrote:
          VPATH is notoriously nonstandard among BSD, GNU and Sun make.
          Suggest that you validate its functioning on all those systems. If
          problematic, it might be too much hassle to make work right,
          despite being
          potentially attractive for simplifying maintenance.

          Dear George,

          Thanks for pointing this out. I've only tested VPATH builds using GNU
          make on linux only, and it worked. I don't have Solaris or Mac
          machines, so is there anybody who can help me test this patch on
          different operating systems other than linux (hopefully using both
          GNU
          make and other make programs)? Thanks!

          It is already stated in the `Readme.buildsac' file that `the build
          goes best with GNU development tools, specifically the GNU gcc and
          the
          GNU make'. I hope that my patch will at least work with GNU make on
          different systems. Hopefully it won't cause problem when using other
          make programs.

          I really like this feature since I can keep my source tree
          uncluttered
          this, and I don't need to make copies of the source tree (which is
          big
          and has thousands of files) at anytime.


          Best regards,

          --
          Kuang He
          Department of Physics
          University of Connecticut
          Storrs, CT 06269-3046

          Tel: +1.860.486.4919
          Web: http://www.phys.uconn.edu/~he/
          _______________________________________________
          sac-dev mailing list
          sac-dev<at>iris.washington.edu
          http://www.iris.washington.edu/mailman/listinfo/sac-dev

          George Helffrich
          george<at>geology.bristol.ac.uk

          _______________________________________________
          sac-dev mailing list
          sac-dev<at>iris.washington.edu
          http://www.iris.washington.edu/mailman/listinfo/sac-dev


          • Kuang He,

            To get it to work I needed to add the following line to confgure.in

            AC_SUBST([abs_top_srcdir])
            AC_SUBST([abs_top_builddir])

            Cheers
            Brian

            On Oct 6, 2008, at 11:47 AM , Brian Savage wrote:

            Kuang He,

            The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir
            is not defined.
            I cannot find a resolution to this, but I will keep looking.

            I needed to rerun the bootstrap script (or autoreconf) as the
            Makefile.in files needed to be regenerated from the Makefile.am files.

            I am using autoconf 2.60 and automake 1.9.6

            Cheers
            Brian


            On Oct 5, 2008, at 7:51 AM , George Helffrich wrote:

            Dear All -

            I can confirm a successful vanilla build of Kuangs distribution
            on MacOS 10.3 and on FreeBSD 6.3.

            However, this build fails on a Solaris 5.7 system (due to a
            possibly unrelated problem). Perhaps Arthur can investigate
            further. My results are:

            ./configure
            checking build system type... sparc-sun-solaris2.7
            checking host system type... sparc-sun-solaris2.7
            checking target system type... sparc-sun-solaris2.7
            ...
            checking for gcc... gcc
            checking for C compiler default output file name...
            configure: error: C compiler cannot create executables
            See `config.log' for more details.
            ------------

            gcc is so old (2.7.2) that is fails configure tests using -V.

            Forcing to use Sun cc is OK until subdirectory configure is used;
            then CC gets forgotten:

            -------------
            ./configure CC=cc
            checking build system type... sparc-sun-solaris2.7
            checking host system type... sparc-sun-solaris2.7
            checking target system type... sparc-sun-solaris2.7
            ...
            configure: creating ./config.status
            config.status: creating src/Makefile
            config.status: creating utils/Makefile
            config.status: creating libedit/Makefile
            config.status: creating Makefile
            config.status: creating inc/config.h
            config.status: executing depfiles commands
            configure:

            Compliation Options for sac (Seismic Analysis Code 101.2)

            CFLAGS =
            LDFLAGS =
            LIBS = -ldl -lm -ltermcap
            Debug =
            Optimization =
            Database = off
            Matlab = off
            X11-buffer = on
            X11-depth = on
            X_LIBS = -L/usr/openwin/lib
            X_CFLAGS = -I/usr/openwin/include
            Readline = off
            Editline = on
            Install Base = /usr/local/sac
            System = sun_solaris2 (sparc-sun-solaris2.7)

            To compile sac type make
            #make
            Making all in libedit
            echo "Creating the Line Editing Library"
            Creating the Line Editing Library
            gzip -dc ./libedit-2.6.9.tar.gz | tar xvf -
            x libedit-2.6.9, 0 bytes, 0 tape blocks
            x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks
            x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks
            x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks
            ...
            (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
            INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
            creating cache ./config.cache
            checking for gcc... gcc
            checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no
            configure: error: installation or configuration problem: C
            compiler cannot create executables.
            *** Error code 1
            make: Fatal error: Command failed for target `lib/libedit.a'
            Current working directory /tmp/sac-101.2/libedit
            *** Error code 1
            make: Fatal error: Command failed for target `all-recursive'
            -----------

            Then,
            -----------
            #make CC=cc
            Making all in libedit
            (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
            INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
            loading cache ./config.cache
            checking for gcc... cc -Xc -D__EXTENSIONS__
            checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall -
            pipe -g3 ) works... no
            configure: error: installation or configuration problem: C
            compiler cannot create executables.
            *** Error code 1
            make: Fatal error: Command failed for target `lib/libedit.a'
            Current working directory /tmp/sac-101.2/libedit
            *** Error code 1
            make: Fatal error: Command failed for target `all-recursive'
            --------------

            The generated Makefiles are so exquisitely baroque as to deter any
            sensible debug effort. Suffice it to say that builds that deviate
            from a default system configuration seem unlikely to work.

            On 1 Oct 2008, at 21:11, Kuang He wrote:

            On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich
            <george<at>gly.bris.ac.uk> wrote:
            VPATH is notoriously nonstandard among BSD, GNU and Sun
            make.
            Suggest that you validate its functioning on all those
            systems. If
            problematic, it might be too much hassle to make work right,
            despite being
            potentially attractive for simplifying maintenance.

            Dear George,

            Thanks for pointing this out. I've only tested VPATH builds using
            GNU
            make on linux only, and it worked. I don't have Solaris or Mac
            machines, so is there anybody who can help me test this patch on
            different operating systems other than linux (hopefully using
            both GNU
            make and other make programs)? Thanks!

            It is already stated in the `Readme.buildsac' file that `the build
            goes best with GNU development tools, specifically the GNU gcc
            and the
            GNU make'. I hope that my patch will at least work with GNU make on
            different systems. Hopefully it won't cause problem when using other
            make programs.

            I really like this feature since I can keep my source tree
            uncluttered
            this, and I don't need to make copies of the source tree (which
            is big
            and has thousands of files) at anytime.


            Best regards,

            --
            Kuang He
            Department of Physics
            University of Connecticut
            Storrs, CT 06269-3046

            Tel: +1.860.486.4919
            Web: http://www.phys.uconn.edu/~he/
            _______________________________________________
            sac-dev mailing list
            sac-dev<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/sac-dev

            George Helffrich
            george<at>geology.bristol.ac.uk

            _______________________________________________
            sac-dev mailing list
            sac-dev<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/sac-dev

            _______________________________________________
            sac-dev mailing list
            sac-dev<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/sac-dev


          • On Mon, Oct 6, 2008 at 11:47 AM, Brian Savage <savage<at>uri.edu> wrote:
            The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir is not
            defined.
            I cannot find a resolution to this, but I will keep looking.

            I needed to rerun the bootstrap script (or autoreconf) as the Makefile.in
            files needed to be regenerated from the Makefile.am files.

            I am using autoconf 2.60 and automake 1.9.6

            Dear Brian,

            I have been using autoconf 2.61 and automake 1.10. According to my
            tests, automake v1.9 does not define abs_* series macros [1], but
            automake v1.10 does.

            The reason I used abs_top_srcdir instead of top_srcdir in several
            Makefile.am's is to solve a VPATH problem I could not solve otherwise.
            For example, in libedit/Makefile.am, there is line that reads:

            LIBEDIT_ENV = env CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
            INSTALL="$(abs_top_srcdir)/config/install-sh"

            If I were to write it using $(top_srcdir), I could not make it work
            for all the following VPATH build cases:

            (1) Build directory is a subdirectory of the source tree:
            cd /path/to/sac/source/code
            mkdir build && cd build
            ../configure

            (2) Build directory is a subdirectory of a subdirectory of the source tree:
            cd /path/to/sac/source/code
            mkdir -p build/test && cd build/test
            ../../configure

            (3) Build directory and source tree are not in the same tree:
            cd /path/to/sac/source/code
            mkdir -p /somewhere/else/build && cd /somewhere/else/build
            /path/to/sac/source/code/configure

            Could you try updating your automake version and try again? Or could
            you figure out a way to solve this problem?

            [1] The autoconf manual indicates that it is autoconf that is
            generating macro like abs_srcdir, abs_top_srcdir, etc.
            http://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables

            It is just automake v1.9 that has not used them (meaning: not
            generating them in Makefile.in's).


            Best regards,

            --
            Kuang He
            Department of Physics
            University of Connecticut
            Storrs, CT 06269-3046

            Tel: +1.860.486.4919
            Web: http://www.phys.uconn.edu/~he/

            • Arthur Snoke
              2008-10-06 21:01:55
              A high percentage of the problems in terms of system compatibility have come
              from libedit.

              Is there perhaps a new release that is more robust?

              • Kuang He
                2008-10-06 21:55:51
                On Mon, Oct 6, 2008 at 2:01 PM, Arthur Snoke <snoke<at>vt.edu> wrote:
                A high percentage of the problems in terms of system compatibility have come
                from libedit.

                Is there perhaps a new release that is more robust?

                Dear Arthur,

                There is a new release below, about 4 years newer than the version we are using.

                http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz

                I don't know about its robustness, though.

                Best regards,

                --
                Kuang He
                Department of Physics
                University of Connecticut
                Storrs, CT 06269-3046

                Tel: +1.860.486.4919
                Web: http://www.phys.uconn.edu/~he/

          • Kuang He,

            Updating to automake 1.10 solves the problem.

            Solaris 2.9 works for both in and out of source directory builds
            Intel OSX does as well.
            Linux too.

            George indicated FreeBSD worked as did solaris 5.7
            Kuang He says it works fine on Cygwin

            Overall this looks good to me.

            Unless there are any objections, I will be adding this to the
            repository.

            Cheers
            Brian



            On Oct 6, 2008, at 11:47 AM , Brian Savage wrote:

            Kuang He,

            The build on my system (OSX/Intel 10.4) fails. The abs_top_srcdir
            is not defined.
            I cannot find a resolution to this, but I will keep looking.

            I needed to rerun the bootstrap script (or autoreconf) as the
            Makefile.in files needed to be regenerated from the Makefile.am files.

            I am using autoconf 2.60 and automake 1.9.6

            Cheers
            Brian


            On Oct 5, 2008, at 7:51 AM , George Helffrich wrote:

            Dear All -

            I can confirm a successful vanilla build of Kuangs distribution
            on MacOS 10.3 and on FreeBSD 6.3.

            However, this build fails on a Solaris 5.7 system (due to a
            possibly unrelated problem). Perhaps Arthur can investigate
            further. My results are:

            ./configure
            checking build system type... sparc-sun-solaris2.7
            checking host system type... sparc-sun-solaris2.7
            checking target system type... sparc-sun-solaris2.7
            ...
            checking for gcc... gcc
            checking for C compiler default output file name...
            configure: error: C compiler cannot create executables
            See `config.log' for more details.
            ------------

            gcc is so old (2.7.2) that is fails configure tests using -V.

            Forcing to use Sun cc is OK until subdirectory configure is used;
            then CC gets forgotten:

            -------------
            ./configure CC=cc
            checking build system type... sparc-sun-solaris2.7
            checking host system type... sparc-sun-solaris2.7
            checking target system type... sparc-sun-solaris2.7
            ...
            configure: creating ./config.status
            config.status: creating src/Makefile
            config.status: creating utils/Makefile
            config.status: creating libedit/Makefile
            config.status: creating Makefile
            config.status: creating inc/config.h
            config.status: executing depfiles commands
            configure:

            Compliation Options for sac (Seismic Analysis Code 101.2)

            CFLAGS =
            LDFLAGS =
            LIBS = -ldl -lm -ltermcap
            Debug =
            Optimization =
            Database = off
            Matlab = off
            X11-buffer = on
            X11-depth = on
            X_LIBS = -L/usr/openwin/lib
            X_CFLAGS = -I/usr/openwin/include
            Readline = off
            Editline = on
            Install Base = /usr/local/sac
            System = sun_solaris2 (sparc-sun-solaris2.7)

            To compile sac type make
            #make
            Making all in libedit
            echo "Creating the Line Editing Library"
            Creating the Line Editing Library
            gzip -dc ./libedit-2.6.9.tar.gz | tar xvf -
            x libedit-2.6.9, 0 bytes, 0 tape blocks
            x libedit-2.6.9/makelist, 6742 bytes, 14 tape blocks
            x libedit-2.6.9/CHANGES, 3853 bytes, 8 tape blocks
            x libedit-2.6.9/INSTALL, 1604 bytes, 4 tape blocks
            ...
            (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
            INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
            creating cache ./config.cache
            checking for gcc... gcc
            checking whether the C compiler (gcc -O -Wall -pipe -g3 ) works... no
            configure: error: installation or configuration problem: C
            compiler cannot create executables.
            *** Error code 1
            make: Fatal error: Command failed for target `lib/libedit.a'
            Current working directory /tmp/sac-101.2/libedit
            *** Error code 1
            make: Fatal error: Command failed for target `all-recursive'
            -----------

            Then,
            -----------
            #make CC=cc
            Making all in libedit
            (cd libedit-2.6.9 && env CFLAGS="-O -Wall -pipe -g3" LDFLAGS=""
            INSTALL="/tmp/sac-101.2/config/install-sh" ./configure --prefix=.. )
            loading cache ./config.cache
            checking for gcc... cc -Xc -D__EXTENSIONS__
            checking whether the C compiler (cc -Xc -D__EXTENSIONS__ -O -Wall -
            pipe -g3 ) works... no
            configure: error: installation or configuration problem: C
            compiler cannot create executables.
            *** Error code 1
            make: Fatal error: Command failed for target `lib/libedit.a'
            Current working directory /tmp/sac-101.2/libedit
            *** Error code 1
            make: Fatal error: Command failed for target `all-recursive'
            --------------

            The generated Makefiles are so exquisitely baroque as to deter any
            sensible debug effort. Suffice it to say that builds that deviate
            from a default system configuration seem unlikely to work.

            On 1 Oct 2008, at 21:11, Kuang He wrote:

            On Wed, Oct 1, 2008 at 3:50 PM, George Helffrich
            <george<at>gly.bris.ac.uk> wrote:
            VPATH is notoriously nonstandard among BSD, GNU and Sun
            make.
            Suggest that you validate its functioning on all those
            systems. If
            problematic, it might be too much hassle to make work right,
            despite being
            potentially attractive for simplifying maintenance.

            Dear George,

            Thanks for pointing this out. I've only tested VPATH builds using
            GNU
            make on linux only, and it worked. I don't have Solaris or Mac
            machines, so is there anybody who can help me test this patch on
            different operating systems other than linux (hopefully using
            both GNU
            make and other make programs)? Thanks!

            It is already stated in the `Readme.buildsac' file that `the build
            goes best with GNU development tools, specifically the GNU gcc
            and the
            GNU make'. I hope that my patch will at least work with GNU make on
            different systems. Hopefully it won't cause problem when using other
            make programs.

            I really like this feature since I can keep my source tree
            uncluttered
            this, and I don't need to make copies of the source tree (which
            is big
            and has thousands of files) at anytime.


            Best regards,

            --
            Kuang He
            Department of Physics
            University of Connecticut
            Storrs, CT 06269-3046

            Tel: +1.860.486.4919
            Web: http://www.phys.uconn.edu/~he/
            _______________________________________________
            sac-dev mailing list
            sac-dev<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/sac-dev

            George Helffrich
            george<at>geology.bristol.ac.uk

            _______________________________________________
            sac-dev mailing list
            sac-dev<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/sac-dev

            _______________________________________________
            sac-dev mailing list
            sac-dev<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/sac-dev


23:36:25 v.b3198453