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 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
-
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
George Helffrich
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<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.
Dear George,
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.
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,
A small addition: I've just tested the `VPATH build' patch on Cygwin,
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,
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,
A small addition: I've just tested the `VPATH build' patch on Cygwin,
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,
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
-
-
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 Helffrich
<george<at>gly.bris.ac.uk> wrote:
VPATH is notoriously nonstandard among BSD, GNU and Sun make.
Dear George,
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.
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<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 Helffrich
<george<at>gly.bris.ac.uk> wrote:
VPATH is notoriously nonstandard among BSD, GNU and Sun make.
Dear George,
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.
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<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 Helffrich
<george<at>gly.bris.ac.uk> wrote:
VPATH is notoriously nonstandard among BSD, GNU and Sun
Dear George,
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.
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<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
Dear Brian,
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
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/
-
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?
-
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
Dear Arthur,
from libedit.
Is there perhaps a new release that is more robust?
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 Helffrich
<george<at>gly.bris.ac.uk> wrote:
VPATH is notoriously nonstandard among BSD, GNU and Sun
Dear George,
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.
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<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
-
-
-
-