taskGNU Astronomy Utilities - Tasks: task #13778, For v0.1: Script to prepare the...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13778: For v0.1: Script to prepare the raw VC source

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  Fri 16 Oct 2015 08:35:39 AM UTC
   
 
Should Start On:  Thu 15 Oct 2015 03:00:00 PM UTC Should be Finished on:  Thu 15 Oct 2015 03:00:00 PM UTC
Category:  Installation Priority:  8
Item Group:  Enhancement Status:  Done
Privacy:  Public Assigned to:  makhlaghi
Percent Complete:  100% Open/Closed:  Closed
Effort:  0.00

Jump to the original submission

Sat 30 Apr 2016 10:10:53 AM UTC, comment #7: 

Thanks to your great work in your bootstrap branch, I implemented in Gnuastro and it is now possible to prepare the version controlled source for ./configure with the single command below (after cloning Gnulib and Autoconf-archives):


./bootstrap --copy --gnulib-srcdir=$DEVDIR/gnulib


The full "Version controlled source" of the book was also re-written and a section ("Bootstrapping") was added to thoroughly explain the process:

http://www.gnu.org/software/gnuastro/manual/html_node/Bootstrapping.html

I just had a comment: there were no comments in your bootstrap.conf file, so to understand everything (and implement and run it) I had to spend a lot of time (maybe as much as you did) trying to understand what these variables are and why you defined them like this.

In the current bootstrap.conf file, the variables and functions that we have added to the Gnulib bootstrap.conf are clearly sparated from from the ones we changed the value of and the ones we didnot change. Also, the reasoning behind the variables and their values is explained.

Since this file will not be updated a lot, even we will forget the details in a few months and have to invest a lot of time again to change something or make an update. Also Gnulib distributes a the bootstrap.conf file also, so it was important to clearly separte our additions/changes from the default ones to be able to easily update our bootstrap.conf if the default one changes. Besides these, in Gnuastro we want to encourage scientists (not necessary trained in these steps) to hack into it. So it is very important to heavily comment everything. If you feel anything is lacking in the current version (and its comments), please feel free to add to them.

Thanks again for the great suggestion and work, Mosè.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 09 Nov 2015 12:40:10 AM UTC, comment #6: 

Thanks, this is really interesting. I will try it out and merge it in master if there are no issues.

Yes, I agree that it is a little strange to only use the autoconf-archive for "m4/ax_pthread.m4". Autoconf-archive  is a very large set of m4 tests and I am sure it will expand to be more complete in the future. With a larger user base (and different operating systems or configurations), in Gnuastro we will probably need more and more of those tests or might even be able to contribute to the archive someday.

For example, currently the ./configure script uses the GNU Coreutils "nproc" utility to get the default number of threads for all the utilities. This is not portable. So Mac OSX users who don't have GNU Coreutils have to specify the number of threads manually at configure time (they will be informed how in the ./configure error message). When such a portable m4 tests is added to Autoconf-archive we will definitely use it to make the installation more portable.

So I thought that having the autoconf-archive usage in place with that one macro for now, will allow us to be alert of their activity and follow their updates better to make maximum use of their efforts in the future.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 08 Nov 2015 04:28:04 PM UTC, comment #5: 

In my "bootstrap" branch I included the "bootstrap" script and "boostrap.conf" configuration file.

In this way, after cloning Gnuastro repository one only has to run


$ ./bootstrap


and the "Version controlled source" section of the manual can be resized ;-)

Actually, I think we can ship the "m4/ax_pthread.m4" file, instead of fetching it from autoconf-archive repository (one Internet connection less required, in addition in the "bootstrap.conf" I used "wget" to download the file, but this may not be present in all systems, in OS X it isn't by default, for one).  Emacs source code has under version control all files they copy from gnulib, but Emacs source code is pretty large anyway, so I don't think it could be useful to do the same for us, but the single "m4/ax_pthread.m4" file won't hurt.

Mosè Giordano <giordano>
Group Member
Sat 07 Nov 2015 09:41:01 AM UTC, comment #4: 

I just found another solution to ease the initial configuration: http://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/bootstrap  I think this does what you want.  In addition, it seems the name "bootstrap" is nowadays preferred over "autogen.sh" by the Autotools project (see https://www.gnu.org/software/automake/faq/autotools-faq.html#What-does-_002e_002fbootstrap-or-_002e_002fautogen_002esh-do_003f).

Mosè Giordano <giordano>
Group Member
Sat 07 Nov 2015 03:17:03 AM UTC, comment #3: 

The Emacs example is great, thanks ;-). I will do this when ever I have some time, but definitely prior to the version 0.1 release.

I have marked this task to be completed before the first release with a "For v0.1:" in the summary and assigned it to my self.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 04 Nov 2015 10:33:14 AM UTC, comment #2: 

Emacs has a script to merge Gnulib into Emacs source: http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=blob;f=admin/merge-gnulib;hb=HEAD  We can take it and adapt to our needs, if needed.  In this way, the autogen.sh script can be given optionally the path to Gnulib, in case one already has it, otherwise it'll run the above script to fetch it from the repository.

Mosè Giordano <giordano>
Group Member
Fri 16 Oct 2015 12:03:25 PM UTC, comment #1: 

I add that in order for the "install" make rule to success one needs to install also help2man, this should be mentioned in the compilation instructions.

Mosè Giordano <giordano>
Group Member
Fri 16 Oct 2015 08:35:39 AM UTC, original submission:  

This was actually suggested by Mosè.

In Gnuastro, the version controlled source is only the raw files that have been created by hand. In order to run ./configure, it is necessary to make a few preparations. They steps are currently explained in the manual and have to be done by hand, but as Mosè pointed out, we should not require the person to get the online manual in order to be able to prepare the source code.

The suggestion was to add a script (autogen.sh) which will check all the conditions (see if Gnulib, autoconf-archive, LaTeX and ImageMagick are ready) and then run all the necessary operations. So basically, after downloading the version controlled source, the person only has to do one more step before running configure

    ./autogen.sh /address/to/top/gnulib/dir

The argument to autogen should be the directory that keeps Gnulib and the autoconf-archive directories which are needed.

Also an explanation should be put in the README file (or a separate README.git file which will only be present in the version controlled source) to explain this for the unprepared user/developer.

For Gnulib and autoconf-archive, it might be possible to use git's submodules. My only problem is tha they appear to only be possible within the same directory as Gnuastro's source files. So having the huge set of Gnulib files within Gnuastro's files will cause some trouble in managing the files (for example in Syncing the project's files across different computers or copying them). Also another issue is when the user already has Gnulib for another project. If so, then they will have two copies of Gnulib on their system.

We can set the autogen.sh script to check Gnulib's commit number, check out the proper commit if it is different, copy the files then set it back to what it was. In this manner the user will only need one copy (clone) of Gnulib and their different software projects can use different commits (s/he should just be careful not to run the two project's autogen.sh scripts at the same time). These are just a suggestion and open to debate.

Mohammad Akhlaghi <makhlaghi>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by giordano (Posted a comment)
  • -email is unavailable- added by makhlaghi (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-30 makhlaghi StatusPostponed Done
        Percent Complete90% 100%
        Open/ClosedOpen Closed
    2015-11-08 giordano Percent Complete10% 90%
    2015-11-07 makhlaghi Percent Complete0% 10%
        Assigned toNone makhlaghi
        SummaryScript to prepare the raw VC source For v0.1: Script to prepare the raw VC source

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code