The bootstrapping script (see Bootstrapping) is not regularly needed: you mainly need it after you have cloned Gnuastro (once) and whenever you want to re-import the files from Gnulib, or Autoconf archives65 (not too common). However, Gnuastro developers are constantly working on Gnuastro and are pushing their changes to the official repository. Therefore, your local Gnuastro clone will soon be out-dated. Gnuastro has two mailing lists dedicated to its developing activities (see Developing mailing lists). Subscribing to them can help you decide when to synchronize with the official repository.
To pull all the most recent work in Gnuastro, run the following command
from the top Gnuastro directory. If you don’t already have a built system,
make distclean. The separate steps are described in detail
$ make distclean && git pull && autoreconf -f
You can also run the commands separately:
$ make distclean $ git pull $ autoreconf -f
If Gnuastro was already built in this directory, you don’t want some
outputs from the previous version being mixed with outputs from the newly
pulled work. Therefore, the first step is to clean/delete all the built
make distclean. Fortunately the GNU build system
allows the separation of source and built files (in separate
directories). This is a great feature to keep your source directory clean
and you can use it to avoid the cleaning step. Gnuastro comes with a script
with some useful options for this job. It is useful if you regularly pull
recent changes, see Separate build and source directories.
After the pull, we must re-configure Gnuastro with
(part of GNU Autoconf). It will update the ./configure script and
all the Makefile.in66 files based on the hand-written configurations (in
configure.ac and the Makefile.am files). After running
autoreconf -f, a warning about
TEXI2DVI might show up, you
can ignore that.
The most important reason for re-building Gnuastro’s build system is to generate/update the version number for your updated Gnuastro snapshot. This generated version number will include the commit information (see Version numbering). The version number is included in nearly all outputs of Gnuastro’s programs, therefore it is vital for reproducing an old result.
As a summary, be sure to run ‘
autoreconf -f’ after every change
in the Git history. This includes synchronization with the main server or
even a commit you have made yourself.
If you would like to see what has changed since you last synchronized your
local clone, you can take the following steps instead of the simple command
above (don’t type anything after
$ git checkout master # Confirm if you are on master. $ git fetch origin # Fetch all new commits from server. $ git log master..origin/master # See all the new commit messages. $ git merge origin/master # Update your master branch. $ autoreconf -f # Update the build system.
git log prints the most recent commit first, add the
--reverse option to see the changes chronologically. To see
exactly what has been changed in the source code along with the commit
message, add a -p option to the
If you want to make changes in the code, have a look at Developing to
get started easily. Be sure to commit your changes in a separate branch
master branch to follow the official repository) and
autoreconf -f after the commit. If you intend to send your
work to us, you can safely use your commit since it will be ultimately
recorded in Gnuastro’s official history. If not, please upload your
separate branch to a public hosting service, for example
GitLab, and link to it in your
report/paper. Alternatively, run
make distcheck and upload the
output gnuastro-X.X.X.XXXX.tar.gz to a publicly accessible webpage
so your results can be considered scientific (reproducible) later.
https://savannah.gnu.org/task/index.php?13993 is defined for you to check if significant (for Gnuastro) updates are made in these repositories, since the last time you pulled from them.
In the GNU build system,
./configure will use the Makefile.in files to create the
necessary Makefile files that are later read by
build the package.