aboutsummaryrefslogtreecommitdiff
path: root/reproduce/software/shell
AgeCommit message (Collapse)AuthorLines
2020-05-01Imported recent changes in Maneage, minor conflicts fixedMohammad Akhlaghi-40/+148
A few small conflicts showed up here and there. They are fixed with this merge.
2020-04-29Reactivated --host-cc config option to use host C compilerMohammad Akhlaghi-1/+0
Until now, if GCC couldn't be built for any reason, Maneage would crash and the user had no way forward. Since GCC is complicated, it may happen and is frustrating to wait until the bug is fixed. Also, while debugging Maneage, when we know GCC has no problem, because it takes so long, it discourages testing. With this commit, we have re-activated the `--host-cc' option. It was already defined in the options of `./project', but its affect was nullified by hard-coding it to zero in the configure script on GNU/Linux systems. So with this commit that has been removed and the user can use their own C compiler on a GNU/Linux operating system also. Furthermore, to inform the user about this option and its usefulness, when GCC fails to build, a clear warning message is printed, instructing the user to post the problem as a bug and telling them how to continue building the project with the `--host-cc' option.
2020-04-28Better explanation at the end of the configurationMohammad Akhlaghi-4/+8
Until now, at the end of the configuration step, we would tell the user this: "To change the configuration later, please re-run './project configure', DO NOT manually edit the relevant files". However, as Boud suggested in Bug #58243, this is against our principle to encourage users to modify Maneage. With this commit, that explanation has been expanded by a few sentences to tell the users what to change and warn them in case they decide to change the build-directory.
2020-04-27Aborting with informative error when GNU gettext not foundMohammad Akhlaghi-1/+39
Until now, we wouldn't explicity check for GNU gettext. If it was present on the system, we would just add a link to it in Maneage's installation directory. However, in bug #58248, Boud noticed that Git (a basic software) actually needs it to complete its installation. Unfortunately we haven't had the tiem to include a build of Gettext in Maneage. Because it is mostly available on many systems, it hasn't been reported too commonly, it also has many dependencies which make it a little time consuming to install. So with this commit, we actually check for GNU gettext right after checking the compiler and if its not available an informative error message is written to inform the user of the problem, along with suggestions on fixing it (how to install GNU gettext from their package manager).
2020-04-26Configure.sh: build directory checked for ability to modify permissionsPedram Ashofteh Ardakani-11/+81
Until now we only checked for the existance and write-ability of the build directory. But we recently discovered that if the specified build-directory is in a non-POSIX compatible partition (for example NTFS), permissions can't be modified and this can cause crashs in some programs (in particular, while building Perl, see [1]). The thing that makes this problem hard to identify is that on such partitions, `chmod' will still return 0 (so it was hard to find). With this commit, a check has been added after the user specifies the build-directory. If the proposed build directory is not able to handle permissions as expected, the configure script will not continue and will let the user know and will ask them for another directory. Also, the two printed characters at the start of error messages were changed to `**' (instead of `--'). When everything is good, we'll use `--' to tell the user that their given directory will be used as the build directory. And since there are multiple checks now, the final message to specify a new build directory is now moved to the end and not repeated in every check. [1] https://savannah.nongnu.org/support/?110220
2020-04-20Configuration: current directory printed properly in stdoutMohammad Akhlaghi-9/+9
Until now, the message that we printed just before starting to build software didn't actually print the current directory, but only `pwd'. With this commit, this is fixed (it uses the `currentdir' variable that is already found before).
2020-04-20Configuration: current directory printed properly in stdoutMohammad Akhlaghi-9/+9
Until now, the message that we printed just before starting to build software didn't actually print the current directory, but only `pwd'. With this commit, this is fixed (it uses the `currentdir' variable that is already found before).
2020-04-20Maneage instead of Template in README-hacking.md and copyright noticesMohammad Akhlaghi-23/+20
Until now, throughout Maneage we were using the old name of "Reproducible Paper Template". But we have finally decided to use Maneage, so to avoid confusion, the name has been corrected in `README-hacking.md' and also in the copyright notices. Note also that in `README-hacking.md', the main Maneage branch is now called `maneage', and the main Git remote has been changed to `https://gitlab.com/maneage/project' (this is a new GitLab Group that I have setup for all Maneage-related projects). In this repository there is only one `maneage' branch to avoid complications with the `master' branch of the projects using Maneage later.
2020-04-18Imported recent updates in Maneage, no conflictsMohammad Akhlaghi-12/+2
There weren't any conflicts in this merge.
2020-04-17Removed confusing comment in configure.sh, and extra variableMohammad Akhlaghi-12/+2
In the previous commit, we remove the `-static' flag from building PatchELF because it wasn't necessary any more. Howver, the comment for the check still included it and could be confusing. This is corrected with this commit. Also, we don't need the `good_static_libc' variable (that was only defined to pass onto PatchELF). This has also been corrected.
2020-04-17Imported recent work in Maneage, minor conflicts fixedMohammad Akhlaghi-8/+6
A few minor conflicts came up that were easily fixed.
2020-04-17IMPORTANT: software config directly under reproduce/software/configMohammad Akhlaghi-8/+6
Until now the software configuration parameters were defined under the `reproduce/software/config/installation/' directory. This was because the configuration parameters of analysis software (for example Gnuastro's configurations) were placed under there too. But this was terribly confusing, because the run-time options of programs falls under the "analysis" phase of the project. With this commit, the Gnuastro configuration files have been moved under the new `reproduce/analysis/config/gnuastro' directory and the software configuration files are directly under `reproduce/software/config'. A clean build was done with this change and it didn't crash, but it may cause crashes in derived projects, so after merging with Maneage, please re-configure your project to see if anything has been missed. Please let us know if there is a problem.
2020-04-05Commenting version numbers with an underscore for LaTeXRaul Infante-Sainz-1/+3
Until now we would simply return the version numbers as they were written into the separate files and situations can happen where the version numbers contain an underscore (`_'). However, this character is a methematical character in LaTeX, causing LaTeX to complain and abort. With this commit, a step has been added at the end of the configure script to convert any possible `_' to `\_'. Once it is commented (a backslash is put behind it), the underscore will be printed as it is in the final PDF. This commit was originally written by Mohammad Akhlaghi
2020-04-04Commenting version numbers with an underscore for LaTeXMohammad Akhlaghi-1/+3
Until now we would simply return the version numbers as they were written into the separate files and situations can happen where the version numbers contain an underscore (`_'). However, this character is a methematical character in LaTeX, causing LaTeX to complain and abort. With this commit, a step has been added at the end of the configure script to convert any possible `_' to `\_'. Once it is commented (a backslash is put behind it), the underscore will be printed as it is in the final PDF.
2020-04-02Imported recent work on Maneage, minor conflicts fixedMohammad Akhlaghi-0/+1620
A few minor conflicts occurred and were fixed.
2020-02-24MissFITS is now added to the templateSurena Fatemi-1/+1
MissFITS is package for manipulating FITS files. I added it as my first commit to the project for educational purposes.
2020-02-13Adding a link to the *crt*.o files in the local install directoryMohammad Akhlaghi-0/+1
Until now, we defined `LIBRARY_PATH' to fix the problem of the `ld' linker of Binutils needing several `*crt*.o' files to run. However, some software (for example ImageMagick) over-write `LIBRARY_PATH', therefore there is no other way than to put a link to these necessary files in our local build directory. With this commit, we fixed the problem by putting a link to the system's relevant files in the local library directory. This fixed the problem with ImageMagick. Later, when we build the GNU C Library in the project, we should remove this step. This bug reported by Raul Castellanos Sanchez.
2020-02-11Configure script won't crash without Fortran compiler, only a warningMohammad Akhlaghi-27/+46
Until now, when a Fortran compiler didn't exist on the host operating system, the configure script would crash with a warning. But some projects may not need Fortran, so this is just an extra/annoying crash! With this commit, it will still print the warning, but instead of a crash, it will just sleep for some seconds, then continue. Later, when if a software needs Fortran, it's building will crash, but atleast the user was warned. In the future, we should add a step to check on the necessary software and see if Fortran is necessary for the project or not. The project configuration should indeed crash if Fortran is necessary, but we should tell the user that software XXXX needs Fortran so we can't continue without a Fortran compiler. Also, a small sentence ("Project's configuration will continue in XXXX seconds.") was added after all the warnings that won't cause a crash, so user's don't think its a crash.
2020-02-01Make called with -k during software buildingMohammad Akhlaghi-2/+2
Until now, Make was just run ordinarily on the two Makefiles of the software building phase. Therefore when there was a problem with one software while building in parallel, Make would only complete the running rules and stop afterwards. But when other rules don't depened on the crashed rule, its a waste of time to stop the whole thing. With this commit, both calls to Make in the `configure.sh' script are done with the `-k' option (or `--keep-going' in GNU Make). With this option, if a rule crashes, the other rules that don't depend on it will also be run. Generally, anything that doesn't depend on the crashed rule will be done. The `-k' option is a POSIX definition in Make, so it is present in most implemenetations (for the call to `basic.mk').
2020-02-01IMPORTANT: reproduce/software/bash renamed to reproduce/software/shellMohammad Akhlaghi-0/+1601
Until now the shell scripts in the software building phase were in the `reproduce/software/bash' directory. But given our recent change to a POSIX-only start, the `configure.sh' shell script (which is the main component of this directory) is no longer written with Bash. With this commit, to fix that problem, that directory's name has been changed to `reproduce/software/shell'.