[gnuastro-devel] [task #13993] Keeping up to date with Gnulib and Autoconf archives

[Mohammad Akhlaghi]

URL:
  <http://savannah.gnu.org/task/?13993>

                 Summary: Keeping up to date with Gnulib and Autoconf archives
                 Project: GNU Astronomy Utilities
            Submitted by: makhlaghi
            Submitted on: Sun 08 May 2016 02:29:40 PM JST
         Should Start On: Sun 08 May 2016 12:00:00 AM JST
   Should be Finished on: Sun 08 May 2016 12:00:00 AM JST
                Category: Development
                Priority: 5 - Normal
              Item Group: Enhancement
                  Status: In Progress
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

The Gnulib and Autoconf archives (which are used during Gnuastro's
bootstrapping) are regularly updated. Not all updates are necessarily
significant for Gnuastro. However, when you are updating your local copy of
Gnulib, if you do notice a relevant update, please post it here if it has not
already been mentioned.

Later, we will have to find a good way to only use a specific commit of Gnulib
during bootstrapping, so all developers are using the same Gnulib snapshot.
Gnulib suggests using Git's submodules, which is also implemented in
./bootstrap, see 

https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html

However, from what I understand of Git's submodules, I don't feel too
comfortable requiring Gnuastro developers to have a whole copy of the Gnulib
history (only for Gnuastro) in their Gnuastro directories. It would be much
more useful if a way could be found for people to keep a local copy of Gnulib
for all their development activities insteading of having a clone for each
project, when they have multiple projects using Gnulib for example. 

A raw (for now only as a discussion, in hope of finding better solutions)
solution that comes to my mind is this: 

The ./bootstrap developers add a hook (maybe called bootstrap_pre_import_hook)
that we can define in bootstrap.conf (something like
bootstrap_post_import_hook). Using this hook, we can checkout a specific
commit in Gnulib's history before gnulib-tool is called and everything is
imported. Afterwards (in bootstrap_post_import_hook) we can checkout Gnulib's
master branch to put it back to its initial state. In this way, a developer
that uses Gnulib for multiple projects just has to make sure that they don't
run two bootstrappings together! 

If no better solution can be found, we can get in touch with the Gnulib
developers to see if they can add this hook to the bootstrap script and use
it.

But until then, lets use this task to track all the relevant changes in Gnulib
for Gnuastro, so Gnuastro developers can check this page to see if they need
to update their local Gnulib, or Autoconf archives clones. This webpage will
be included in the documentation, for easy access until we find a solution.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?13993>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/