No configure file

[maddyscientist]

The installation instructions for QIO state to use the configure script to compile and install QIO. However, there is no pre-supplied configure script included, only configure.ac.

Attempting to generate the configure file by running autoconf is unsuccessful. Generating configure gives a slew of errors, and the generated configure file doesn't run

cirrascale@CirrascaleUbuntu:~/kate/qio$ autoconf
configure.ac:8: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:190: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:287: error: possibly undefined macro: AM_CONDITIONAL

cirrascale@CirrascaleUbuntu:~/kate/qio$ ./configure
./configure: line 2405: syntax error near unexpected token `subdir-objects'
./configure: line 2405: `AM_INIT_AUTOMAKE(subdir-objects)'

This is using autoconf version 2.69.

[maddyscientist]

As suggested by @bjoo, I tried running autoreconf. This results in a configure script that seems to run, but gives the following warning

=== configuring in other_libs/c-lime (/home/cirrascale/kate/qio/other_libs/c-lime)
configure: WARNING: no configuration information is in other_libs/c-lime

When I try to build QUO, I get the following failure

cirrascale@CirrascaleUbuntu:~/kate/qio$ make
Making all in other_libs
make[1]: Entering directory `/home/cirrascale/kate/qio/other_libs'
Making all in c-lime
make[2]: Entering directory `/home/cirrascale/kate/qio/other_libs/c-lime'
make[2]: *** No rule to make target `all'.  Stop.
make[2]: Leaving directory `/home/cirrascale/kate/qio/other_libs/c-lime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cirrascale/kate/qio/other_libs'
make: *** [all-recursive] Error 1

Looks like a problem in c-lime configuration.

[bjoo]

Hi Kate,
When you checked out qio, did you do it recursively?
Ie did you

git clone —recursive git@github.com:usqcd-software/qio.git

( or the old way:

git clone git@gihub.com:usqcd-software/qio.git

Now get the submodules:

cd qio
git submodule update —init —recursive

Now that you have it regenerate the build-system — this should

reautoconf the other_libs/c_lime too if it has been recursively cloned.

autoreconf -f -i

Good luck, and best wishes,

B

On Dec 10, 2015, at 5:05 PM, maddyscientist notifications@github.com wrote:

As suggested by @bjoo, I tried running autoconfig. This results in a configure script that seems to run, but gives the following warning

=== configuring in other_libs/c-lime (/home/cirrascale/kate/qio/other_libs/c-lime)
configure: WARNING: no configuration information is in other_libs/c-lime

When I try to build QUO, I get the following failure

cirrascale@CirrascaleUbuntu:~/kate/qio$ make
Making all in other_libs
make[1]: Entering directory /home/cirrascale/kate/qio/other_libs' Making all in c-lime make[2]: Entering directory/home/cirrascale/kate/qio/other_libs/c-lime'
make[2]: *** No rule to make target all'. Stop. make[2]: Leaving directory/home/cirrascale/kate/qio/other_libs/c-lime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cirrascale/kate/qio/other_libs'
make: *** [all-recursive] Error 1

Looks like a problem in c-lime configuration.

—
Reply to this email directly or view it on GitHub.

---

Dr Balint Joo High Performance Computational Scientist
Jefferson Lab
12000 Jefferson Ave, Suite 3, MS 12B2, Room F217,
Newport News, VA 23606, USA
Tel: +1-757-269-5339, Fax: +1-757-269-5427

email: bjoo@jlab.org

[maddyscientist]

Thanks @bjoo this did the trick. The problem is therefore outstanding that the installation instructions do not mention the need to

1. Use autoreconf
2. Do a recursive git clone
   This issue should stay open open until the instructions are updated as such.

[maddyscientist]

I see this issue still hasn't been fixed, and I just noticed the tarballs are broken as they do not include the c-lime source code.

[lucasbrasilino]

Well... so valuable info about recursively cloning qio should be in the README....

[martin-ueding]

In the first post, there was the following issue:

cirrascale@CirrascaleUbuntu:~/kate/qio$ ./configure
./configure: line 2405: syntax error near unexpected token `subdir-objects'
./configure: line 2405: `AM_INIT_AUTOMAKE(subdir-objects)'

This happens because the aclocal.m4 is not created with the version of Autotools that is running on the machine. Therefore there are macros missing.

I have written a comprehensive installation script for Chroma + QPhiX using Intel C++ and Intel MPI on a Xeon Architecture. With the marconi script, there also is something for KNL.

The problematic part are also the submodules. They all need the autoreconf -fi step done. However, that will fail if it is run top-down, it needs to be run bottom-up!

See my autotools-dance and autoreconf-if-needed functions:

autotools-dance() {
    aclocal
    automake --add-missing --copy || autoreconf -f || automake --add-missing --copy
    autoreconf -f
}

autoreconf-if-needed() {
    if ! [[ -f configure ]]; then
        if [[ -f .gitmodules ]]; then
            for module in $(git submodule foreach --quiet --recursive pwd | tac); do
                pushd "$module"
                autotools-dance
                popd
            done
        fi

        autotools-dance
    fi

It is important to iterate through the git submodules in a backward way (therefore the tac, which is a reverse cat). Then calling the auto* programs a couple of times until it works. Perhaps autoreconf -fi is sufficient, I have not updated the scripts. This variant has worked well for me, though.

The trouble with Autotools is that end-users are not expected to have access to the version control system. The developers (with VCS access) should generate the configure and ship that as a tar archive. Today, people just clone the git repository. But then they need to run the needed steps.

Perhaps the autoreconf.sh script should just add the option -i such that missing files are installed as well.

@lucasbrasilino: I now always check whether there is a .gitmodules file on GitHub, then I know to use the --recursive flag when cloning. Perhaps that should be the default behavior though.