Closed blippy closed 8 years ago
The test suite should now work fully.
I'm adding the test environment here.
:+1:
Don't worry about the echo "PASS: foo b" line. That was for testing purposes. It is later replaced by proper working code.
It looks like you over wrote this in another commit... If you want you could interactive rebase to cleanup your history then force push to blippy:master
but I'm not fussed about it.
Ideally I wouldn't have made this commit, but I wanted to do it in order to fix an annoying "autoreconf -i" warning over on the master branch.
Yeah, stash can cause issues. I'm a big fan of rebasing when working from a private fork, before merging a PR, but as I said I'm not fussed.
git rebase --interactive HEAD~5
on blippy:master
if you want to give it a whirl, but I wouldn't bother.
I could have "stashed" my work, I suppose, but when I tried that before, it gave me a lot of troubles. So I decided to make a commit, even though it doesn't do too much.
I still haven't determined how to resolve conflicts when popping stashes....
@blippy let me checkout the PR locally and give it a spin, then I'll add my official PR code review approval if all looks good.
@zbeekman Do you work together with @milancurcic, like in the same room? I got that impression because you both seemed to comment at roughly the same time.
Maybe it's just a timezone thing.
I'm still almost completely new to autools, so I'm learning the ropes on how it works.
nope, but we're both US eastern daylight savings time, I think he's in FL, I'm in DC... you're doing great with auto tools, better than me!
Amazing stuff, thanks guys! I will do a local test as well..
Just tested, works as expected. Thanks!!
Am I missing something? It seems that make check
isn't running the executable for the tests:
$ autoreconf -ivf && ./configure --disable-silent-rules && make check
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gfortran... gfortran
checking whether the Fortran compiler works... yes
checking for Fortran compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... yes
checking whether gfortran accepts -g... yes
checking for ranlib... ranlib
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/lib/Makefile
config.status: creating src/tests/Makefile
config.status: creating datetime-fortran.pc
Making check in src/lib
gfortran -c -Wall -O0 -C -fbacktrace mod_constants.f90
gfortran -c -Wall -O0 -C -fbacktrace mod_strftime.f90
gfortran -c -Wall -O0 -C -fbacktrace mod_timedelta.f90
gfortran -c -Wall -O0 -C -fbacktrace mod_datetime.f90
mod_datetime.f90:710:0:
strftime = strftime(1:n-1)
^
Warning: '.__var_1' may be used uninitialized in this function [-Wmaybe-uninitialized]
gfortran -c -Wall -O0 -C -fbacktrace mod_clock.f90
gfortran -c -Wall -O0 -C -fbacktrace datetime.f90
ar ruv libdatetime.a datetime.o mod_clock.o mod_datetime.o mod_timedelta.o mod_strftime.o mod_constants.o
ar: creating archive libdatetime.a
a - datetime.o
a - mod_clock.o
a - mod_datetime.o
a - mod_timedelta.o
a - mod_strftime.o
a - mod_constants.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libdatetime.a(datetime.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libdatetime.a(mod_strftime.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libdatetime.a(mod_constants.o) has no symbols
Making check in src/tests
gfortran -c -Wall -O0 -C -fbacktrace -I../lib datetime_tests.f90
gfortran -g -O2 datetime_tests.o -L../lib -ldatetime -o datetime_tests
warning: no debug symbols in executable (-arch x86_64)
/Applications/Xcode.app/Contents/Developer/usr/bin/make check-TESTS
tests-env.sh: line 9: datetime_tests: command not found
sed: illegal option -- r
usage: sed script [-Ealn] [-i extension] [file ...]
sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
============================================================================
Testsuite summary for datetime-fortran 1.4.1
============================================================================
# TOTAL: 0
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[1]: Nothing to be done for `check-am'.
In particular: tests-env.sh: line 9: datetime_tests: command not found
I'm going to see if I can patch this to fix the issue.
@milancurcic did you encounter this in your testing?
No, here is the output on my machine:
$ make check
Making check in src/lib
make[1]: Entering directory `/home/milan/datetime-fortran/src/lib'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/milan/datetime-fortran/src/lib'
Making check in src/tests
make[1]: Entering directory `/home/milan/datetime-fortran/src/tests'
make check-TESTS
make[2]: Entering directory `/home/milan/datetime-fortran/src/tests'
make[3]: Entering directory `/home/milan/datetime-fortran/src/tests'
make[4]: Entering directory `/home/milan/datetime-fortran/src/tests'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/milan/datetime-fortran/src/tests'
============================================================================
Testsuite summary for datetime-fortran 1.4.1
============================================================================
# TOTAL: 170
# PASS: 170
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[3]: Leaving directory `/home/milan/datetime-fortran/src/tests'
make[2]: Leaving directory `/home/milan/datetime-fortran/src/tests'
make[1]: Leaving directory `/home/milan/datetime-fortran/src/tests'
make[1]: Entering directory `/home/milan/datetime-fortran'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/home/milan/datetime-fortran'
Is that executing after extracting a tarball for from source (master
)
About this:
tests-env.sh: line 9: datetime_tests: command not found
perhaps you just need a ./datetime_tests
if you don't have ./
in your path. I patched a similar issue where top-level Makefile.am didn't have ./
for mkdist.sh
and scrub-clean.sh
. Try adding ./
by hand in tests-env.sh
.
Is that executing after extracting a tarball for from source (master)
Yes.
yes, I'm guessing that's the issue... I'll investigate
I've come up with a fix. PR incoming shortly.
It might be safer to issue the command:
autoreconf -ivf && ./configure --disable-silent-rules && make && make check
which includes 'make' before 'make check'
make check
depends on make all
for autoconf/automake generated build systems by default. Let me know if you find that isn't the case.
My mistsake. You're right.
Problem was: src/lib/Makefile.am:7: warning: variable 'nodist_SOURCES' is defined but no program or src/lib/Makefile.am:7: library has 'nodist' as canonical name (possible typo)
Now fixed.