aboutsummaryrefslogtreecommitdiff
path: root/reproduce/software/make
AgeCommit message (Collapse)AuthorLines
2020-04-18Imported recent updates in Maneage, no conflictsMohammad Akhlaghi-29/+23
There weren't any conflicts in this merge.
2020-04-18Properly adding libiconv to the libraries that libstdc++ links withMohammad Akhlaghi-1/+4
Of the GCC dynamically linked libraries we need to manually add RPATH to all and for `libstdc++' we also need to tell it to link with `libiconv'. Until now, the conditional to check for libstdc++ was not working and thus libiconv wasn't been added to it. With this commit the conditional has been corrected and is now working. Also, to help in reading the logs, an echo statement was added after every call to PatchELF.
2020-04-17Replaced name of directory under akhlaghi.org as backup serverMohammad Akhlaghi-17/+17
Until now, when a the raw tarball of some software wasn't usable, I would put it under my own webpage, or `akhlaghi.org/reproduce-software'. That same address was also used as a backup server. However, now the project has a proper name: Maneage. So I changed the directory on my own server to `akhlaghi.org/maneage-software'. With this commit, this new address has replaced the old one. But to avoid crashes in projects that haven't yet merged with the main Maneage branch, the old `reproduce-software' still works (its actually a symbolic link to the new directory now).
2020-04-17Patchelf is now built dynamicallyMohammad Akhlaghi-11/+2
Until a few commits ago, PatchELF was built statically because it was used to patch `libstdc++' at the end of the GCC building phase, but PatchELF also depends on `libstdc++', so it would crash. However, recently when patching the GCC libraries, we don't directly apply Patchelf to the library, first we copy it to a temporary place, do the patching, then put it in its proper place. So the problem above won't happen any more. With this commit, I am thus removing the static flag from patchelf and letting it built dynamically all the time. The main problem was that some systems don't have a static C++ library, so PatchELF couldn't be built statically. Instead of adding more checks, we just fixed the core foundation of the problem.
2020-04-17Imported recent work in Maneage, minor conflicts fixedMohammad Akhlaghi-17/+19
A few minor conflicts came up that were easily fixed.
2020-04-17IMPORTANT: software config directly under reproduce/software/configMohammad Akhlaghi-14/+16
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-13Installation year removed from TeXLive installationMohammad Akhlaghi-7/+5
TeXLive recently transitioned from its 2019 version to its 2020 version thanks to Elham Saremi's trial of the this project. The fact that traditionally Maneage installs all TeXLive packages in a per-year directory is very annoying and required an update in the core Maneage system every year. So I suddently recognized that we can fix this by setting a different name for the directory holding the release year. This has been implemented with this commit. I have also done this change in the main Maneage branch for other projects to also benefit from this correction.
2020-04-13Configure (TeXLive): year correction also in high-level packagesMohammad Akhlaghi-1/+1
In the previous commit, I removed the year from the basic installation of TeXLive packages, but I forgot to correct this in the high-level TeXLive packages! This is corrected with this commit.
2020-04-13Configure (TeXLive): Year of distribution no longer in directoryMohammad Akhlaghi-6/+4
It is this time of year again: TeXLive has transitioned to its 2020 release and the year is imprinted into the installation directory of TeXLive. Until now, we have had to manually change this year and it caused complications and was very annoying. With this commit, the explicit year has been removed from TeXLive's installation and we now simply put a `maneage' instead of the year. I tried this on another system and it worked nicely. Until the time that we can fully install LaTeX packages from source tarballs, this is the best thing we could do for now.
2020-04-12Configure (numpy): added --std=c99 to CFLAGS to fix errorMohammad Akhlaghi-0/+1
Elham Saremi recently reported the following errors when building Numpy in numpy/core/src/npysort/radixsort.c.src: "error: 'for' loop initial declarations are only allowed in C99 or C11 mode". After some searching, I found Issue 14147[1] on Numpy's main repository about the same problem. As described there, apparently Numpy needs C99 compiler, but doesn't check for it or set it manually (for some strange reason, leaving it to the packagers to check if they want!!!). Any way, after a check with Elham, we were able to fix it by adding the `--std=c99' to CFLAGS of Numpy's build and with this commit, it is now being implemented in the core Maneage to not cause a problem in any other project. [1] https://github.com/numpy/numpy/issues/14147
2020-04-06Astropy now depending on the Expat library to fix internal conflictRaul Infante-Sainz-10/+26
Until now, Astropy was instructed to build its own internal copy of the Expat library. However, with the recent commits before, Maneage now includes an installation of Expat and Astropy can't keep the two (its internal version and the project's version) separate, so they conflict and don't let Astropy get built. With this commit, the problem is fixed by setting the Expat library as an explicit dependency of Astropy and asking Astropy to ignore its internal copy. While doing this, I recognized that it is much easier and elegant to add steps in various stages of the `pybuild' function through hooks instead of variables. So the fifth argument of the `pybuild' function was removed and now it actually checks if hooks are defined as functions and if so, they will be called. The `pyhook_after' function was also implemented in the installation of `pybind11' (which needed it, given that the 5th argument of `pybuild' was removed) and after doing a test-build, I noticed that two lines were not ending with a `\' in `boost' (a dependency of `pybind11'). Commit written originally by Mohammad Akghlaghi
2020-04-06Corrected typo in the definition of pybuildMohammad Akhlaghi-1/+1
Raul noticed this during the build: I had mistakenly put an extra `&&' at the start of the line where the line before ended with a `;'.
2020-04-05Astropy now depending on the Expat library to fix internal conflictMohammad Akhlaghi-9/+25
Until now, Astropy was instructed to build its own internal copy of the Expat library. However, with the recent commits before, Maneage now includes an installation of Expat and Astropy can't keep the two (its internal version and the project's version) separate, so they conflict and don't let Astropy get built. When trying to build Manage (the actual project, not this paper) after applying the commits before there, Raul discovered this problem. With this commit, the problem is fixed by setting the Expat library as an explicit dependency of Astropy and asking Astropy to ignore its internal copy. While doing this, I recognized that it is much easier and elegant to add steps in various stages of the `pybuild' function through hooks instead of variables. So the fifth argument of the `pybuild' function was removed and now it actually checks if hooks are defined as functions and if so, they will be called. The `pyhook_after' function was also implemented in the installation of `pybind11' (which needed it, given that the 5th argument of `pybuild' was removed) and after doing a test-build, I noticed that two lines were not ending with a `\' in `boost' (a dependency of `pybind11').
2020-04-05The build of M4 and XLSX I/O on macOS has been fixedRaul Infante-Sainz-6/+37
Until now, the M4 that was built on macOS had internal problems (as discussed in #1): it would simply print `Abort trap: 6' in the output and abort. After looking at the build of Homebrew, I noticed that they apply a patch (correct one line) to fix this problem. To be able to apply that patch on macOS systems, I had fully open up the build recipe of M4 and atleast on the testing system, it was built successfully. Also, after successfully building M4, and thus Autoconf and thus Minizip, we were able to build XLSX I/O on a macOS and found out that the internal library's full address wasn't being put in the libraries and executables. With this commit, we now use macOS's `install_name_tool' to correct the positions of the two `libxlsxio_*' libraries in all its executables. This commit was originally written by Mohammad Akhlaghi
2020-04-05Including version number of Minizip in its installation targetRaul Infante-Sainz-1/+1
Until this commit, only the word `Minizip' was written into the Minizip installation target (without the version number of Minizip). With this commit, this minor bug has been fixed by using the appropiate Make variable: `$(minizip-version)'.
2020-04-05Building Minizip 1.x instead of Minizip 2.xRaul Infante-Sainz-15/+62
Minizip is a dependency of XLSX I/O and until now, I was just using the most recent version I found (2.9.2), but XLSX I/O is written for the Minizip 1.x series, not 2.x. Somehow it didn't cause a crash on my computer!!! I think XLSX I/O's CMake is instructed to look into system directories by default when it doesn't find the directories in the given places. And because I had installed Minizip on my operating system, it did't complain. Upon trying the build on their systems, Yahya, Raul and Zahra reported a failure in the build of XLSX I/O which was due the to the problem above (we were installing the wrong version of Minizip!). With this commit, this has been fixed by installing the 1.x series of Minizip (whish is actually installed within zlib!). This commit was original done by Mohammad Akhlaghi.
2020-04-04The build of M4 and XLSX I/O on macOS has been fixedMohammad Akhlaghi-5/+36
Until now, the M4 that was built on macOS had internal problems (as discussed in #1): it would simply print `Abort trap: 6' in the output and abort. After looking at the build of Homebrew, I noticed that they apply a patch (correct one line) to fix this problem. To be able to apply that patch on macOS systems, I had fully open up the build recipe of M4 and atleast on the testing system, it was built successfully. Also, after successfully building M4, and thus Autoconf and thus Minizip, we were able to build XLSX I/O on a macOS and found out that the internal library's full address wasn't being put in the libraries and executables. With this commit, we now use macOS's `install_name_tool' to correct the positions of the two `libxlsxio_*' libraries in all its executables.
2020-04-04Building Minizip 1.x instead of Minizip 2.xMohammad Akhlaghi-15/+63
Minizip is a dependency of XLSX I/O and until now, I was just using the most recent version I found (2.9.2), but XLSX I/O is written for the Minizip 1.x series, not 2.x. Somehow it didn't cause a crash on my computer!!! I think XLSX I/O's CMake is instructed to look into system directories by default when it doesn't find the directories in the given places. And because I had installed Minizip on my operating system, it did't complain. Upon trying the build on their systems, Yahya, Raul and Zahra reported a failure in the build of XLSX I/O which was due the to the problem above (we were installing the wrong version of Minizip!). With this commit, this has been fixed by installing the 1.x series of Minizip (whish is actually installed within zlib!).
2020-04-02Imported recent work on Maneage, minor conflicts fixedMohammad Akhlaghi-110/+195
A few minor conflicts occurred and were fixed.
2020-04-01Removed multiple tabs in MissFITS tarball definitionRaul Infante-Sainz-1/+1
With this commit, multiples tabs in the definition of MissFITS tarball have been removed. Now they are white spaces.
2020-03-20Adding PyYAML, Html5lib, and Beautifulsoup4 as prerequsites of AstropyRaul Infante-Sainz-4/+4
Until this commit, PyYAML was not set as prerequisite of Astropy. This package is an optional dependency of Astropy for some particular functions. However, we have already included PyYAML into this project so it is available. With this commit, PyYAML has been set as a prerequisite of Astropy. In addition to this, Html5lib and Beautifulsoup4 have been also added as prerequsites of Astropy (and removed from Astroquery prerequisites). I noticed that both of them are optional dependencies of Astropy.
2020-03-17Astroquery updated to version 0.4Raul Infante-Sainz-1/+1
In the last update of Astropy to version 4.0 they removed some things that the previous version of Astroquery needs. As a consequence, it is also necessary to update the Astroquery version to be a ble to run with the Astropy 4.0. With this commit, the update of Astroquery to it most recent version (0.4) has been done.
2020-02-24MissFITS is now added to the templateSurena Fatemi-0/+7
MissFITS is package for manipulating FITS files. I added it as my first commit to the project for educational purposes.
2020-02-19Building of GCC now only done when /dev/shm has more than 10GB freeMohammad Akhlaghi-4/+21
Until now, like all software on GNU/Linux systems GCC would be built in RAM (to speed up the build slightly and also not put too much stress on the HDDs/SSDs). But some systems don't have enough RAM for building GCC and will complain and crash. With this commit, we have added a check on the amount of free space in the `build_tmp' directory (which will be `/dev/shm' on GNU/Linux systems). If the amount of free space isn't more than 10GB, then GCC won't be built there and a temporary directory will be built under the `$(BDIR)/software' directory for it. This bug was found by Zahra Sharbaf. This fixes bug #57853.
2020-02-16Building XLSX I/O and its dependencies: expat and minizipMohammad Akhlaghi-1/+33
Until now, there was no easy way to read/write `.xlsx' files (Microsoft Excel spreadsheets) within the template. But XLSX I/O provides to simple programs and some libraries to easily convert `.xlsx' files to CSV that can easily be read by any tool. This has also been implemented in the core template branch.
2020-02-16XLSX I/O installed with its two dependencies: expat and minizipMohammad Akhlaghi-0/+32
XLSX I/O is a very simple and fast program and library for reading and writing `.xls' and `.xlsx' files (mainly used by Microsoft Excel) to CSV files. It has two separate executables that can be called for an Excel file and will output a CSV plain text file that can then be used within the pipeline with more standard tools.
2020-02-13Corrected version of Texinfo when reportingMohammad Akhlaghi-1/+1
Until now we were mistakenly reporting the version of SED instead of Texinfo. With this commit, we corrected it! This was reported by Raul Infante Sainz.
2020-02-13Adding a link to the *crt*.o files in the local install directoryMohammad Akhlaghi-1/+16
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-11Using backup server when original download server failsMohammad Akhlaghi-6/+19
Until now, the main download script could only check one server for the given URL. However, ultimately the actual server that a file is downloaded from is irrelevant for this project: we actually check its checksum. Especially in the case of software (which are distributed over many servers), this can usually be very annoying: the servers may not properly communicate with the running system and even the 10 trials won't be enough. With this commit, the download script `reproduce/analysis/bash/download-multi-try' can take a new optional argument (a 5th argument). It assumes this argument is a space-separated list of server(s) to use as backup for the original URL. When downloading from the original URL fails, it will look into this list and try downloading the same file from each given server.
2020-02-01IMPORTANT: reproduce/software/bash renamed to reproduce/software/shellMohammad Akhlaghi-6/+6
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'.
2020-01-31Configure step: compiler checks done before basic settingsMohammad Akhlaghi-1/+6
Until now, the project would first ask for the basic directories, then it would start testing the compiler. But that was problematic because the build directory can come from a previous setting (with `./project configure -e'). Also, it could confuse users to first ask for details, then suddently tell them that you don't have a working C library! We also need to store the CPATH variable in the `LOCAL.conf' because in some cases, the compiler won't work without it. With this commit, the compiler checking has been moved at the start of the configure script. Instead of putting the test program in the build directory, we now make a temporary hidden directory in the source directory and delete that directory as soon as the tests are done. In the process, I also noticed that the copyright year of the two hidden files weren't updated and corrected them.
2020-01-27Initial scripts compatible with Dash (minimalistic POSIX)Mohammad Akhlaghi-1/+1
Until now, the initial project scripts were primarily tested with GNU Bash. But Bash is not generally available on all systems (it has many features beyond POSIX). Because of this, effectively we were imposing the requirement on the user that they must have Bash installed. We recently started this with setting the shebang of `project' and `reproduce/software/bash/configure.sh' to `/bin/sh'. After doing so, Raul and Gaspar reported an error on their systems. To fix the problem, I installed Dash (a minimalist POSIX-compliant shell) on my computer and temporarily set the shebangs to `/bin/dash', ran the project configuration step and fixed all issues that came up. With this commit, it can go all the way to building GCC on my system's Dash. After this stage (when `high-level.mk' is called), there is no problem, because we have our own version of GNU Bash and that installed version is used. Probably some more issues still remain and will hopefully be found in the future. While doing this, I also noticed the following two minor issues: - The `./project configure' option `--input-dir' was not recognized because it was mistakenly checking `--inputdir'. It has been corrected. - The test C programs now use the `<<EOF' method instead of `echo'. - In `basic.mk', the extra space between `syspath' and `:=' was removed (it was an ancient relic!).
2020-01-22Perl is now a dependency of Coreutils, LD_LIBRARY_PATH in basic.mkMohammad Akhlaghi-67/+80
Until now Perl was built after Coreutils, but I recently noticed that Coreutils actually uses Perl while creating its manpages. So it is now built before Coreutils. Also, while testing on an Amazon AWS EC2 server, we noticed that Coreutils can't build its man page for `md5sum'. The problem was found to be due to the fact that until now, we weren't actually setting LD_LIBRARY_PATH to our installed library path in `basic.mk'. Therefore, it would crash because the server had an older version of OpenSSL than the one that the template's Coreutils was built with. In the meantime (while addressing the issues above, because we only had one thread on the AWS server) I also noticed a few programs that were using a summarize compilation command (that just prints `CC xxx.c' instead of the whole command) so I fixed them by adding `V=1'. This bug was found by Idafen Santana PĂ©rez.
2020-01-20Added figure showing project's file structureMohammad Akhlaghi-7/+26
It was a little hard to describe the file structure so instead of using a standard listing as most papers do, I thought of showing the file and directory structure as boxes within each other (modeled on the Gnome disk-utility). Some other polishing was done throughout the paper also.
2020-01-20IMPORTANT!!! Configuration Makefiles now have a .conf suffixMohammad Akhlaghi-12/+12
Until now, the configuration Makefiles (in `reproduce/software/config/installation' and `reproduce/analysis/config') had a `.mk' suffix, similar to the workhorse Makefiles. Although they are indeed Makefiles, but given their nature (to only keep configuration parameters), it is confusing (especially to early users) for them to also have a `.mk' (similar to the analysis or software building Makefiles). To address this issue, with this commit, all the configuration Makefiles (in those directories) are now given a `.conf' suffix. This is also assumed for all the files that are loaded. The configuration (software building) and running of the template have been checked with this change from scratch, but please report any error that may not have been noticed. THIS IS AN IMPORTANT CHANGE AND WILL CAUSE CRASHES OR UNEXPECTED BEHAVIORS FOR PROJECTS THAT HAVE BRANCHED FROM THIS TEMPLATE. PLEASE CORRECT THE SUFFIX OF ALL YOUR PROJECT'S CONFIGURATION MAKEFILES (IN THE DIRECTORIES ABOVE), OTHERWISE THEY AREN'T AUTOMATICALLY LOADED ANYMORE.
2020-01-19GNU Make updated to version 4.3Mohammad Akhlaghi-1/+1
GNU Make 4.3 was just announced, so I have updated it here is well. This was important because until now the installable version was in alpha-mode (4.2.90), now its a stable version.
2020-01-19LIBRARY_PATH is set accordingly based on the hostMohammad Akhlaghi-4/+18
Until now, GCC wouldn't build properly on Debian-based operating systems because `ld' needed to link with several necessary C library features like `crti.o' and `crtn.o' (this is an `ld' issue, not GCC). The solution is to add the directory containing them to `LIBRARY_PATH'. In the previous commit, I actually searched for these files, but while testing on another system, I noticed that it can be problematic (other architectures may exist). With this commit, we are actually finding the build architecture of the running GCC (which is the same as the `ld') and using that to fix a fixed directory to `LIBRARY_PATH'.
2020-01-18TeXLive version printing updated to include revisionMohammad Akhlaghi-7/+26
Until now, when find the versions of the TeXLive packages, we would assume that `cat-date' is always present (because some packages don't have a version!). However, apparently an update has been made in the TeXLive Manager (`tlmgr') and `cat-date' is no longer present! As a result, none of the TeXLive packages were being printed. With this commit, it now assumes that `revision' is always present for every package, but it also attempts to read `cat-date' (for backwards compatability). When `cat-version' isn't present, it will try printing `revision' and if that is also not present, it will print the date.
2020-01-13Adding X11 libraries path to LDFLAGS in Ghostscript installationRaul Infante-Sainz-1/+4
Until this commit, the checking of X11 installation done to ensure that it is already available in the host system was crashing in macOS systems. The reason is that the place of the X11 libraries use to be `/opt/X11/lib' in macOS systems. With this commit, this issue has been fixed by adding this directory to the LDFLAGS.
2020-01-13Updated verion of Astropy to 4.0 the most recent oneRaul Infante-Sainz-1/+1
Newer versions of Astropy package has been released. With this commit, it has been updated. It has been increased from v3.2.1 to v4.0
2020-01-11Corrected markdown code notations in one README.mdMohammad Akhlaghi-4/+4
In markdown, to specify that part of the text should be shown as code we need to put it between two `. But in `reproduce/software/make/README.md', the code parts started with ` and finished in ' (like the file name above). With this commit, this has been corrected and it will display properly on web browsers.
2020-01-01Copyright statements updated to include 2020Mohammad Akhlaghi-9/+9
Now that its 2020, its necessary to include this year in the copyright statements.
2019-12-18Fixing Libxml2 checksum variable nameRaul Infante-Sainz-1/+1
Until this commit, the number `2' was missing in the checksum variable name of that library. It was `libxml-checksum' but it should be `libxml2-checksum'. With this commit, this issue has been fixed.
2019-12-18Removed extra backslash in Jeepney prerequisitesRaul Infante-Sainz-1/+1
An extra backslash in the prerequisites of Jeepney Python package was causing a crash in the installation of that software. With this commit, this problem has been fixed by removing the backslash.
2019-12-14R explicitly built without support for OpenMPMohammad Akhlaghi-1/+2
OpenMP takes a LONG TIME to build, so to keep things reproducible we are explicitly disabling OpenMP, if a user needs OpenMP, its trivial to just add it as a prerequisite of R. The problem is that in some scenarios (based on other dependencies and when they were built in the build directory), OpenMP may be present when R is being installed and in other it may not. We don't want the result to be different between the two builds.
2019-12-14Core R package is now in templateMohammad Akhlaghi-0/+14
With this commit, we now have the core R interpretter within the template. We should later include instructions to install R packages (possibly in a separate top-level Makefile like Python).
2019-12-04Perl built without -shared on macOSMohammad Akhlaghi-1/+11
Until now, while building Perl, the `-Dlddlflags="-shared $$LDFLAGS"' option was being used for all systems. However, this caused `symbol(s) not found for architecture x86_64' problems on macOS systems. With this commit, this configure option is only passed for GNU/Linux systems. With it, Perl can be built nicely on both GNU/Linux and macOS.
2019-12-04Checking for necessary X11 libraries before building GhostscriptMohammad Akhlaghi-1/+35
Until now, Ghostscript was using some host system's X11 libraries during its build (and later at run-time). We should ideally install all these necessary libraries within the template (Task #15481). But right now we are too busy. As a temporary work-around we try building a small dummy program that links with some of those libraries before attempting to built Ghostscript. If it fails, then a notice is printed with the cause and explaining a temporary solution is suggested: how to install those libraries on the system when you have root access.
2019-11-08Matplotlib problem on macOS system with GNU GCC fixedMohammad Akhlaghi-3/+9
Until now when building Matplotlib on macOS systems, we were using the default C compiler. However, while Yahya Sefidbakht (previously) and Mahdieh Nabavi (now) were trying to build the template, on their macOS using the GNU Compiler Collection (GCC), we found that Matplotlib needs special macOS headers that GCC doesn't recognize. With this commit, when Matplotlib is being built on macOS systems, it uses `clang' and this fixed the problem (so far checked on Mahdieh's machine).
2019-11-08Minor corrections applied in software buildsMohammad Akhlaghi-4/+9
While working on a different branch to build the GNU C Library, I noticed a few places in the template that need corrections which are now applied: 1. A new-line character after the "C compiler works" notice at the start of the configure script. 2. Removing possible `::' in the `LD_LIBRARY_PATH' definition of `basic.mk'. Note that its not necessary in the other steps because we don't use any outside-defined `LD_LIBRARY_PATH'. 3. Building GMP for C++ and also with `--enable-fat'. 4. Removing the unpacked Perl tarball directory after its installation.