aboutsummaryrefslogtreecommitdiff
path: root/reproduce/src/make/dependencies.mk
AgeCommit message (Collapse)AuthorLines
2018-11-29Ignoring building of GCC for pipelineMohammad Akhlaghi-10/+14
GNU Binutils (which provides the GNU Linker) is not ported to Mac OS systems. GCC also takes a very long time to build, and if we are to still have linking problems with LLVM's linker, it would be better to just ignore GCC also and use the system's C compiler and linker together. So for the time being, GCC isn't a main target of the basic dependencies and won't be installed. But we have kept the rules that were checked on a GNU/Linux operating system.
2018-11-29GCC is now installed by the pipelineMohammad Akhlaghi-31/+30
The pipeline now installs GCC and all its necessary prerequisites.
2018-11-28Changed -rpath to -rpath-link for LLVMMohammad Akhlaghi-1/+2
The linker of LLVM version 10.0.0 (clang-1000.11.45.5) doesn't recognize the `-rpath' linker option! After some searching, apparently it does recognize `-rpath-link' so we are testing with that now.
2018-11-28Better control of shared library linkingMohammad Akhlaghi-13/+17
Until now we weren't explicity writing the full path of the dynamic libraries necessary for linking a program. But now with `-Wl,-rpath=$(ildir)' we ensure that the linker keeps the address of the dynamic libraries necessary for linking at linking time, not running time. Also, `pkg-config' is also built when preparing the basics. Several other minor corrections were made thanks to the great help of Raúl Infante Sainz.
2018-11-26High-level dependencies build without system's PATHMohammad Akhlaghi-27/+11
The high-level dependencies are now built without having access to the system's PATH. To do this, all the necessary software that we aren't building ourselves are now brought into the installed `bin/' directory using a symbolic link to the corresponding software on the host. To do this, it was also necessary to increase the number of basic/low-level packages that we are building, and add several more (Diffutils and Findutils). With this process in place, we now have a list of the exact software packages that we are not building our selves, enabling easy building of all such dependencies in the future.
2018-11-25Pipeline now downloads and uses an input datasetMohammad Akhlaghi-1/+6
In most analysis situations (except for simulations), an input dataset is necessary, but that part of the pipeline was just left out and a general `SURVEY' variable was set and never used. So with this commit, we actually use a sample FITS file from the FITS standard webpage, show it (as well as its histogram) and do some basic calculations on it. This preparation of the input datasets is done in a generic way to enable easy addition of more datasets if necessary.
2018-11-22Ghostscript was updated to version 9.26Mohammad Akhlaghi-1/+1
A new version of the ghostscript package is now available, so the used version in the pipeline (previously 9.25) has been incremented to 9.26.
2018-11-21Changing of README files in checklistMohammad Akhlaghi-1/+0
When you point to this project, the `README.md' file is the default file that opens on GitLab and other online git repositories. Since a reproduction pipeline project is different from the actual pipeline, its best for the default text that opens to describe the paper, not the pipeline. The old `README.md' is also kept, but its now called `REAME-pipeline.md'.
2018-11-20Configure script passes if TeX Live was not finalizedMohammad Akhlaghi-55/+67
When there is a problem in creating the final TeX Live installation, the previous version of the pipeline would not understand and just finish! We would later have problems in building the paper. So the following series of steps were taken: to keep the recipes in a shorter and easier to understand way, the steps to install TeX Live are now one rule (that produce `.local/bin/texlive-ready-tlmgr' when its successful), and the steps to install the necessary packages are in another rule (that produce `.local/bin/texlive-ready' when its successful). When control comes back inside configure, if `.local/bin/texlive-ready' isn't there (something failed during the TeX Live installation, or building packages), then the whole TeX Live installation directory (`.local/texlive') will be deleted along with the two output files. This will help ensure that future steps can check the availablility of a working TeX Live in the pipeline.
2018-11-20Not including system's libraries in high-level dependenciesMohammad Akhlaghi-4/+7
The system's libraries are no longer used in building the higher-level dependencies. Also, thanks to Raul Infante Sainz, we found out that Bash's build script was still removing the extra directory information (not good!).
2018-11-20GNU Coreutils now built in basic dependenciesMohammad Akhlaghi-29/+17
GNU Coreutils are basic programs that can help in the configuration of higher-level programs. Because of that, it was a dependency of almost all software built in `dependencies.mk'. To make things more clear, easier to read and faster (when building in parallel), the building of Coreutils is now moved to the `dependencies-basic.mk' rules. There, it is built along-side Bash. Since `dependenceis-basic.mk' is run and completed before `dependencies.mk', with this, we can be sure that Coreutils is present by the time we want to build the higher-level programs. Also, Zlib is now added as a dependency of Git also (it is necessary for its build).
2018-11-19Libtool set as Gnuastro dependencyMohammad Akhlaghi-2/+3
Until now, we were building Libtool as a high-level `top-level-programs' software. But all tools that use the `./configure' script already have a version of Libtool in them. So ultimately the `libtool' in the PATH is not used. However, in the case of Gnuastro, we need libtool for running BulidProgram. So in effect, its a dependency of Gnuastro.
2018-11-19Removed GNU Binutils, CMake's built with its own bootstrapMohammad Akhlaghi-66/+106
When the C compiler is not GNU GCC, linking with GNU Binutils is going to cause problems. So until the time that we can include GCC into this pipeline, its best to avoid Binutils also. Also, for building CMake, we were relying on an installed CMake, but now, we are using its own `./bootstrap' script, so it can be built even if the host system doesn't have CMake. Also, for TeX Live, we are now setting a custom file as main target to avoid complications with symbolic links as targets in Make. Finally, when the user says they don't want to re-write an existing configuration file, no extra notices will be printed and the configure script will immediately start building programs.
2018-11-18Updated README and README.md for new dependency building featuresMohammad Akhlaghi-1/+1
The two README files have been updated to explain the new feature of downloading and building dependencies.
2018-11-18Pipeline also installs TeX live and necessary packagesMohammad Akhlaghi-18/+72
Since the final product of the pipeline is a LaTeX-created PDF file, it was necessary to also have LaTeX within the pipeline. With this commit, TeX Live is also built as part of the configuration and all the necessary packages to build the PDF are also installed and mentioned in the paper along with their versions.
2018-11-17TeX Live also built within the pipeline (no extra packages yet)Mohammad Akhlaghi-2/+22
TeX Live is now also downloaded and built by the reproduction pipeline. Currently on the basic (TeX and LaTeX) source is built but no extra packages, so the PDF building will fail. We'll add them in the next commit.
2018-11-15Binutils and other compressors also included in pipelineMohammad Akhlaghi-18/+14
To have better control over the build, GNU Binutils, Bzip2, GNU Gzip, and XZ Utils have also been added to the pipeline. Some other minor cleanups and fixes were also implemented throughout the process.
2018-11-14Lzip and Tar also built as basic dependenciesMohammad Akhlaghi-32/+34
To ensure the easy unpacking and building of the programs, Lzip and Tar are now also build during the initial setup phase. Some minor corrections were also applied to make things cleaner and smoother.
2018-11-14Configuration stops if a dependency cannot be builtMohammad Akhlaghi-26/+1
Until now, we used semicolons in Make's Call function definitions to build the programs with GNU build system or CMake. Therefore, if any step of the process failed, the rest would be ignorant to it and pass. Now, we use `&&' to separate the different processing steps. In this way, we can be sure that if any of them fails (during configuration, or building for example), the pipeline will also stop and not continue to the next command (in the same recipe). Since the two Make Call functions were identical in the two `dependencies-basic.mk' and `dependencies.mk', they are now in one file to be imported in both. This bug was found by Raul Infante Sainz.
2018-11-14./configure and building of Bash and Make with more basic toolsMohammad Akhlaghi-30/+4
After a test by Raúl Infante Sainz, we found out that the configure script and the Make script for Bash and Make are making too many assumptions on more recent versions of both. As a result, it couldn't be built. Therefore, the `configure' script was modified to not use more recent tools like `readlink' (to find the absolute address of a relative one). It was also re-organized to not have to read the configuration parameters from a text file. The parameters are directly read from the command-line and are written into the proper file afterwards. This removes the need to opening a text editor by the user (which also caused problems on Raúl's system). To fix the Make version issue, the building of Bash and Make are now done in a new Makefile (`reproduce/src/make/dependencies-basic.mk'). This file doesn't make many of the assumptions that were made in `dependencies.mk'. So it should hopefully work on any version of Make. To help in debugging, for now, the Makefile of configure, are asked to work on one thread (the `-j' option is commented in the `configure'). But after checks, we'll fix this.
2018-11-13Most library versions are now also checkedMohammad Akhlaghi-28/+37
All the libraries that define their version string as a macro in their headers are now also checked in `reproduce/src/make/initialize.mk'. Also, the CFITSIO tarball now follows the same versioning style as the rest of the tarballs: a script is added to convert the version string into what is included in the tarball.
2018-11-12Corrected CFITSIO building recipeMohammad Akhlaghi-1/+1
We were mistakenly using GSL's name for the unpacked tarball.
2018-11-12Libcurl, Git, CMake, TIFF, Zlib also built at configure timeMohammad Akhlaghi-87/+116
During the configuration step several new programs that were necessary for a more complete controlled environment are now also downloaded and built statically.
2018-11-12Added tarball host webp addresses for downloadMohammad Akhlaghi-12/+15
The host web address of most of the necessary packages was blank (filled with `WWWWWWWWWWWWWWWW' as a place holder). They now point to the correct webpages.
2018-11-12Dependencies built at the start of the pipelineMohammad Akhlaghi-0/+254
To enable easy/proper reproduction of results, all the high-level dependencies are now built within the pipeline and installed in a fixed directory that is added to the PATH of the Makefile. This includes GNU Bash and GNU Make, which are then used to run the pipeline. The `./configure' script will first build Bash and Make within itself, then it will build All the dependencies are also built to be static. So after they are built, changing of the system's low-level libraries (like C library) won't change the tarballs. Currently the C library and C compiler aren't built within the pipeline, but we'll hopefully add them to the build process also. With this change, we now have full control of the shell and Make that will be used in the pipeline, so we can safely remove some of the generalities we had before.