NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Running into a similar situation I found it best to actually commit the configure script and macros into project, and re-commit them sepparately every time I had to re-autoreconf. A problem in this approach is that different people working on the project with slightly different autotools versions would almost always generate different files should they autoreconf, and everyone must be well aware of sepparately committing the autogenerated scripts/macros. Something that is almost always ignored around. Although the negative effect on polluting the commit history, the resulting commit tends to work anywhere. If the project is in fortran, further problem happens, as there are helper modules to treat fortran-specific matters, as these modules are not present by default (installed thru autoconf-archives package), some may actually break and commit the broken scripts until someone re autoreconfs and commit the fixed version again. But I think that in a controlled environment, with people dedicated in reviewing commits sent to the repos, this can work just fine, ensuring new versions of the scripts/macros are only pushed once there's new autotools release or relevant files have changed. By last, maybe the best solution would be just ensuring an 'autoreconf' was re-issued every time the repo is pulled or the files are packaged. In my environment, people were having hard times understanding this, so the pollution approach was more comfortable around. - fabricio Ward Fisher <wfisher@xxxxxxxxxxxxxxxx> wrote: >Hi Daniel, > >With our move to GitHub, the 'tagged' releases are now packaged version >of the source, whereas before we prepared source packages uses the the >'make dist' command provided by autotools. The difference is that the >latter created the 'configure' script while the former does not. > >In the short term, you may generate the necessary scripts by invoking >'autoreconf -i -f', or you can configure/build using 'cmake' >(instructions here: >http://www.unidata.ucar.edu/software/netcdf/docs/netCDF-CMake.html). I >am working on how to properly add the 'configure' script and other files >generated by autoreconf to the repository. > >Sorry for the inconvenience, > >-Ward > >On 8/9/13 10:30 AM, Daniel Packman wrote: >> I don't see the top level "configure" script after unpacking netcdf 4.3.0. >> Are we supposed to create this via "autoconf"? I tried this and got >> >> configure.ac:39: error: possibly undefined macro: AM_INIT_AUTOMAKE >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >> >> I blindly forged ahead and ran configure getting this error message: >> >> configure: netCDF 4.3.0 >> configure: error: cannot find install-sh or install.sh in "." "./.." >> "./../.." >> >> >> Suggestions are welcome. >> >> _______________________________________________ >> netcdfgroup mailing list >> netcdfgroup@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ > >_______________________________________________ >netcdfgroup mailing list >netcdfgroup@xxxxxxxxxxxxxxxx >For list information or to unsubscribe, visit: >http://www.unidata.ucar.edu/mailing_lists/
netcdfgroup archives: