aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorLines
2020-07-17README.md now has description of building project in DockerMohammad Akhlaghi-0/+218
Docker is a "container" technology that allows an almost independent operating system run on the host. It is useful when the host OS doesn't support some features or has internal problems (for example its C library or C compiler have problems). Fortunately a Maneaged project can easily be built within a Docker image and a minimal image operating system. With this commit, a section has been added to 'README.md' to describe this process. Each step of the Dockerfile is explined, to help users that may not be too familiar with Docker, or help Docker user who are not familiar with Maneage.
2020-07-07Fixed typo that lead to crash when building healpyMarius Peper-1/+1
Until now, if a project needed the healpy software package, Maneage would crash with the following error message (abridged for full name in build directory). This was caused by a typo in the version of 'healpix' (the dependency of 'healpy'). make: *** No rule to make target '.../version-info/proglib/healpix-' With this commit, the typo in line 334 of 'python.mk' is fixed, so that when '$(ipydir)/healpy-$(healpy-version)' gets called it correctly searches for a rule to make '$(ibidir)/healpix-$(healpix-version)'.
2020-07-07Project distribution tarball can account for no PDFs in tex/tikzMohammad Akhlaghi-1/+6
Until now the './project make dist' command implicitly assumed that the 'tex/tikz' directory always contains PDF files (because of the 'cp tex/tikz/*.pdf $$dir/tex/tikz' line). This was annoying for projects that don't use TiKZ or PGFPlots to generate their plots, and they had to manually comment this line. With this commit a check has been placed to see if any PDF files exist in there at all. If there aren't PDF files, the 'cp' command above is ignored.
2020-07-05Configure script prefers clang for macOS systemsMohammad Akhlaghi-96/+129
In the previous commit (Commit 1bc00c9: Only using clang in macOS systems that also have GCC) we set the used C compiler for high-level programs to be 'clang' on macOS systems. But I forgot to do the same kind of change in the configure script (to prefer 'clang' when we are testing for a C compiler on the host). With this commit, the compiler checking phases of the configure script have been improved, so on macOS systems, we now first search for 'clang', then search for 'gcc'. While doing this, I also noticed that the 'rpath' checking command was done before we actually define 'instdir'!!! So in effect, the 'rpath' directory was being set to '/lib'! So with this commit, this test has been taken to after defining 'instdir'.
2020-07-05Removing possibly existing paper.bbl before remaking itMohammad Akhlaghi-0/+6
Until now, when the bibliography file ('paper.bbl') had a LaTeX-related error (for example the journal name was a LaTeX macro that isn't defined), the first 'pdflatex' command that is run before 'biber' would crash, not allowing the project to reach 'biber'. So the user would have to manually remove 'paper.bbl' before running './project make'. With this commit, we remove any possibly existing 'paper.bbl' file before rebuilding it. Generally, this also helps in keeping things clean during the generation of the new bibliography. This bug was found by Mahdieh Nabavi.
2020-07-05Only using clang in macOS systems that also have GCCMohammad Akhlaghi-27/+58
Until now, when Maneage was built on a macOS that had both a clang and GCC, we would make links to both. But this cause many conflicts in some high-level programs (for example Numpy and etc, all the programs where we have explicity set 'export CC=clang' before the build recipe). This happens because the GCC that is built on a macOS isn't complete for some operations. To fix this problem, when we are on a macOS, we explicity set 'gcc' to point to 'clang' and 'g++' to point to 'clang++'. We also don't link to the host's C-preprocessor ('cpp') on macOS systems because this is only a GNU feature and using the GNU CPP is also known to have some basic problems. For example this was reported by Mahdieh Nabavi (which was the main trigger for this work): ld: Symbol not found: ___keymgr_global Referenced from: /Users/Mahdieh/build/software/installed/bin/cpp Expected in: /usr/lib/libSystem.B.dylib Also, to avoid linking to another link on the host tools (in the 'makelink' function of 'basic.mk'), we are now using 'realpath'.
2020-07-04Commit hash of Maneage branch used to build project as LaTeX macroMohammad Akhlaghi-12/+19
To help in the documentation, the Git hash of the Maneage branch commit that the project has most recently merged with (or branched from) is now also provided as a LaTeX macro ('\maneageversion'). It is calculated in 'reproduce/analysis/make/initialize.mk' (in the recipe to 'initialize.tex').
2020-07-04Better names and comments in INPUTS.confMohammad Akhlaghi-29/+33
Until now, the dataset's configuration names had a 'WFPC2' prefix. But this very alien to anyone that is not familiar with the history of the Hubble Space Telescope (the camera is no longer used! Its just used here since its one of the standard FITS files from the FITS standard webpage). With this commit the variable names have been modified to be more readable and clear (having a 'DEMO-' prefix). Also the comments of 'INPUTS.conf' (describing the purpose of each variable) were edited and made more clear.
2020-07-04Some command line messages of ./project didn't mention shellMohammad Akhlaghi-2/+3
Until now, the 'shell' mode of the './project' script was missing in the top output of './project --help' and in the error message printed when no operation was given, or when more than one operation was given. This is now corrected.
2020-07-04Improved comments in paper.mk and README.mdMohammad Akhlaghi-8/+14
In 'README.md' I tried to explain a little better that TeXLive will only install its necessary packages, not the full TeXLive library! Also in paper.mk, I slightly improved the comments with very minor edits. Both these parts are slated to go into the core Maneage branch, so its important to maintain them here for now.
2020-07-04Citing Maneage paper in acknowledgmentsMohammad Akhlaghi-10/+10
In the previous commit, the modified abstract of the acknowledgments only included the URL of Maneage, but its more formal to cite the Maneage paper, the URL is already present in the paper.
2020-07-04Corrected Acknowledgments section in default paperMohammad Akhlaghi-14/+14
Until now, the acknowledgment section didn't contain the new name of Maneage and it also included an acknowledgment of Gnuastro (which is not appropriate for a general project which may not use Gnuastro). With this commit this is fixed.
2020-07-03Edits in REAME.md on Docker images and internet for TeXLiveMohammad Akhlaghi-9/+13
The explanation was made more clear.
2020-07-01Properly accounting for space characters in host's PATHMohammad Akhlaghi-12/+20
Until now, when reading the host's PATH environment variable we weren't accounting for directory names with a space character. This was most prominently visible in the 'low-level-links' step where we put links to some core system components into the project's build directory (mainly for prorietary systems like macOS). To address the problem, double quotations have been placed around the part that we extract 'ccache' from the PATH, and the part where we make the symbolic link. In the process the comments above 'makelink' were made more clear and 'low-level-links' now depends on 'grep' (which is the highest-level program it uses). This bug was reported by Mahdieh Navabi.
2020-07-01Corrected small typo: ny --> anyMohammad Akhlaghi-1/+1
This was pointed out by Mervyn O'Luing.
2020-07-01Minor typo corrected in referencing LibidnRaul Infante-Sainz-1/+2
Until this commit, once Libidn was installed, insted of its own name and version, the name and version of Libjpeg were saved (in the target if Libidn). This robably come from a copy/paste of the rule. With this commit, this minor bug has been corrected. I also added my name as an author of `reproduce/software/make/xorg.mk' Makefile since I added some code there.
2020-07-01Edited the Docker container explanations in README.mdMohammad Akhlaghi-79/+99
The explanations are now more clear for someone that is less familiar with Docker.
2020-06-30Imported Maneage infrastructure, no conflictsMohammad Akhlaghi-3/+5
There weren't any conflicts in this merge.
2020-06-30Proper deletion of util-linux source after successfully building itMohammad Akhlaghi-1/+3
After recently adding util-linux to Maneage build-tree, we had forgot to delete the unpacked and built source directory after it was installed! This has been corrected with this commit.
2020-06-30Entered data and software directories stored as absolute addressesMohammad Akhlaghi-2/+2
Until now, when the user specified an input and software directory, the raw string they entered was used. But when this string was a relative location, this could be problematic in general scenarios. With this commit, the same function that finds the absolute location of the build directory is used to find the absolute address of the data and software directories.
2020-06-30The distclean target accounts for non-existance of git hooksMohammad Akhlaghi-1/+1
Until now, when the user wanted to complete remove all built files (including software), the './project make distclean' command would fail if the git hooks weren't installed. They are present when the project's configuration has been successfully finished, but this bug can happen when trying to re-do an incomplete build. With this commit, this is fixed by adding an '-f' has been added before the 'rm' command for the Git hooks. This commit was also done in the core Maneage branch.
2020-06-30The distclean target accounts for non-existance of git hooksMohammad Akhlaghi-1/+1
Until now, when the user wanted to complete remove all built files (including software), the './project make distclean' command would fail if the git hooks weren't installed. They are present when the project's configuration has been successfully finished, but this bug can happen when trying to re-do an incomplete build. With this commit, this is fixed by adding an '-f' has been added before the 'rm' command for the Git hooks.
2020-06-30README.md: improved explanation on running DockerMohammad Akhlaghi-57/+124
With the new features in Maneage to install the necessry Xorg libraries, the explanations of the Docker image creation also needed to be updated.
2020-06-30Imported recent improvements in Maneage, no conflictsMohammad Akhlaghi-52/+382
There weren't any conflicts in this merge.
2020-06-30Implemented comments by Mervyn O'LuingMohammad Akhlaghi-19/+17
Mervyn had read the paper and provided some interesting thoughts that I tried to implement. Mervyn's comments are shown below. I just haven't addressed the last point yet, because I am affraid it may make the text too long (we are already on the boundary of the word-limit). We have already discussed that it is a good research topic, and have hopefully triggered the curiosity of the readers to test it ;-). ------------------- Page 2: Regarding Criterion 1: Completeness. A project must be self contained? So this includes not requiring root or administrator privileges. This suggests that the project is only made open after the development has been completed? Regarding Criterion 5: 'a clerk can do it' -- in the pc world that we live in could this be taken as a disparaging comment? Page 5: 'The C library is linked with all programs, and this dependence can hypothetically hinder exact reproducibility of results, but we have not encountered this so far.' - what do you think might happen if this does affect reproducibility? Do you have a plan to deal with this? Or are you going to wait until you hear of such cases as the number will probably be small? Have you done probability analysis to show that the rates are likely to be very small? Or should you have a disclaimer with maneage?
2020-06-30Core Xorg libraries necessary for Ghostscript now includedMohammad Akhlaghi-50/+380
Until now, in order to build Ghostscript, the project used the host's Xorg libraries. This was because we hadn't yet added the necessary build rules for them. With this commit, the instructions to build the necessary Xorg libraries for Ghostscript have also been added. Also, the shared Ghostscript library has been built with this commit and two sets of standard fonts are also included, setting us on the path to build TeXLive from source later. This task was done with the help and support of Raul Infante-Sainz.
2020-06-28Bison installation on macOS fixed by updating to version 3.6Raul Infante-Sainz-2/+2
Until this commit, there was a problem when building Bison in parallel in macOS systems. With this commit, this problem has been fixed by updating Bison to its most recent version (3.6).
2020-06-28README.md now has descriptions to build a DockerfileMohammad Akhlaghi-29/+154
Docker is a very commonly used program these days for building projects in an almost independent operating system. So the instructions to build a Dockerfile for the project were added in README.md.
2020-06-28Zenodo identifier is extracted automatically from metadata.confMohammad Akhlaghi-3/+7
Until now, the Zenodo identifier was manually written in the paper. But now we have the Zenodo DOI in 'metadata.conf', so its much more robust to get it from there (in case updated versions of the paper is published).
2020-06-27Imported recent work in master, minor conflict fixed in paper.mkMohammad Akhlaghi-2251/+2674
Only two conflicts came up in the newly added comments of 'paper.mk' in the Maneage branch. It happened because in this project we don't use 'pdflatex', but 'latex' alone.
2020-06-27IMPORTANT: many improvements to low-level software building phaseMohammad Akhlaghi-2193/+2468
POSSIBLE EFFECT ON YOUR PROJECT: The changes in this commit may only cause conflicts to your project if you have changed the software building Makefiles in your project's branch (e.g., 'basic.mk', 'high-level.mk' and 'python.mk'). If your project has only added analysis, it shouldn't be affected. This is a large commit, involving a long series of corrections in a differnt branch which is now finally being merged into the core Maneage branch. All changes were related and came up naturally as the low-level infrastructure was improved. So separating them in the end for the final merge would have been very time consuming and we are merging them as one commit. In general, the software building Makefiles are now much more easier to read, modify and use, along with several new features that have been added. See below for the full list. - Until now, Maneage needed the host to have a 'make' implementation because Make was necessary to build Lzip. Lzip is then used to uncompress the source of our own GNU Make. However, in the minimalist/slim versions of operating systems (for example used to build Docker images) Make isn't included by default. Since Lzip was the only program before our own GNU Make was installed, we consulting Antonio Diaz Diaz (creator of Lzip) and he kindly added the necessary functionality to a new version of Lzip, which we are using now. Hence we don't need to assume a Make implementation on the host any more. With this commit, Lzip and GNU Make are built without Make, allowing everything else to be safely built with our own custom version of GNU Make and not using the host's 'make' at all. - Until recently (Commit 3d8aa5953c4) GNU Make was built in 'basic.mk'. Therefore 'basic.mk' was written in a way that it can be used with other 'make' implementations also (i.e., important shell commands starting with '&&' and ending in '\' without any comments between them!). Furthermore, to help in style uniformity, the rules in 'high-level.mk' and 'python.mk' also followed a similar structure. But due to the point above, we can now guarantee that GNU Make is used from the very first Makefile, so this hard-to-read structure has been removed in the software build recipes and they are much more readable and edit-friendly now. - Until now, the default backup servers where at some fixed URLs, on our own pages or on Gitlab. But recently we uploaded all the necessary software to Zenodo (https://doi.org/10.5281/zenodo.3883409) which is more suitable for this task (it promises longevity, has a fixed DOI, while allowing us to add new content, or new software tarball versions). With this commit, a small script has been written to extract the most recent Zenodo upload link from the Zenodo DOI and use it for downloading the software source codes. - Until now, we primarily used the webpage of each software for downloading its tarball. But this caused many problems: 1) Some of them needed Javascript before the download, 2) Some URLs had a complex dependency on the version number, 3) some servers would be randomly down for maintenance and etc. So thanks to the point above, we now use the Zenodo server as the primary download location. However, if a user wants to use a custom software that is not (yet!) in Zenodo, the download script gives priority to a custom URL that the users can give as Make variables. If that variable is defined, then the script will use that URL before going onto Zenodo. We now have a special place for such URLs: 'reproduce/software/config/urls.conf'. The old URLs (which are a good documentation themselves) are preserved here, but are commented by default. - The software source code downloading and checksum verification step has been moved into a Make function called 'import-source' (defined in the 'build-rules.mk' and loaded in all software Makefiles). Having taken all the low-level steps there, I noticed that there is no more need for having the tarball as a separate target! So with this commit, a single rule is the only place that needs to be edited/added (greatly simplifying the software building Makefiles). - Following task #15272, A new option has been added to the './project' script called '--all-highlevel'. When this option is given, the contents of 'TARGETS.conf' are ignored and all the software in Maneage are built (selected by parsing the 'versions.conf' file). This new option was added to confirm the extensive changes made in all the software building recipes and is great for development/testing purposes. - Many of the software hadn't been tested for a long time! So after using the newly added '--all-highlevel', we noticed that some need to be updated. In general, with this commit, 'libpaper' and 'pcre' were added as new software, and the versions of the following software was updated: 'boost', 'flex', 'libtirpc', 'openblas' and 'lzip'. A 'run-parts.in' shell script was added in 'reproduce/software/shell/' which is installed with 'libpaper'. - Even though we intentionally add the necessary flags to add RPATH inside the built executable at compilation time, some software don't do it (different software on different operating systems!). Until now, for historical reasons this check was done in different ways for different software on GNU/Linux sytems. But now it is unified: if 'patchelf' is present we apply it. Because of this, 'patchelf' has been put as a top-level prerequisite, right after Tar and is installed before anything else. - In 'versions.conf', GNU Libtool is recognized as 'libtool', but in 'basic.mk', it was 'glibtool'! This caused many confusions and is corrected with this commit (in 'basic.mk', it is also 'libtool'). - A new argument is added to the './project' script to allow easy loading of the project's shell and environment for fast/temporary testing of things in the same environment as the project. Before activating the project's shell, we completely remove all host environment variables to simulate the project's environment. It can be called with this command: './project shell'. A simple prompt has also been added to highlight that the user is using the Maneage shell!
2020-06-25Check if there is enough available in selected build directoryPedram Ashofteh Ardakani-2/+45
Until now, Maneage would accept the given build directory, regardless of the free memory available there. This could cause confusing situations for new users who don't know about the minimum storage requirement. With this commit, after all other checks on the given build directory are completed, the configure script will check the available space and warns the user if there is less than almost 5GB free space available in the build directory (with a 5 second delay). It won't cause a crash because some projects may require roughly smaller than this space (the default only needs roughly 2GB). But we also don't want the host's partition to get too close to being full, causing them problems elsewhere. We can change the behavior as desired in future commits.
2020-06-22Acknowledged very usful discussions at the AMIGA group of IAAMohammad Akhlaghi-1/+2
I visited the AMIGA group in January this year and we had some very useful discussion on Maneage.
2020-06-21Minor edits to clarify some pointsMohammad Akhlaghi-241/+116
After going through Terry's corrections, some things were clarified more. Technically, I realized that many new-lines were introduced and corrected them. Also, in Roberto's biography, I noticed that compared to the others it has too much non-reproducibility details, so I removed the redundant parts for this paper.
2020-06-21Edits by Terry MahoneyTerry Mahoney-147/+285
Terry is an astronomer at IAC's Scientific Editorial Service and kindly agreed to review this paper for us and actually pushed this commit. I am just adding a commit message here.
2020-06-19Removing preparation-done.mk when cleaning by ./project make cleanRaul Infante-Sainz-0/+1
Until this commit, the file `BDIR/software/preparation-done.mk' were not removed when cleaning the project with `./project make clean'. This file is generated in the preparation of the data during the analysis step. However, the cleaning is expected to remove anything generated in the analysis process! Step by step, with the commands: ./project make ---> Will make the preparation and analysis ./project make clean ---> Will remove all analysis outputs (but not `preparation-done.mk') ./project make ---> Won't do the preparation, only analysis! However, in the last step it should do the preparation again, because the input data could have change for any reason. With this commit, the file `BDIR/software/preparation-done.mk' is removed when cleaning the project, and consequently, in the analysis step the input data is prepared.
2020-06-18Fixed small bug that was introduced four commits agoRaul Infante-Sainz-4/+4
In Commit 105467fe6402 (Software tarballs are downloaded even if not built), we introduced tests to download the tarballs of software even if they don't need to be built on the respective host. However some small typos in the checks existed that could cause a crash on macOS. In particular in the building of PatchELF and libbsd we had forgot to add the necessary 'x' before the 'yes' in the conditional to check if a we are on macOS or not. With this commit these two checks have been corrected. Also, in the building of 'isl' and 'mpc', we now check for 'host_cc' (signifying that the user wants to use their host C compiler for the high-level step) instead of 'on_mac_os'. The reason is that even on non-macOS systems, a user may not want to build the C compiler from scratch and use the '--host-cc' option. In such cases, they don't need to compile 'isl' and 'mpc'.
2020-06-18Better step-by-step implementation of the data-lineage figureMohammad Akhlaghi-104/+87
Until now, the data-lineage figure's step-by-step feature (using the macros defined at the top) didn't correspond to the new format! It was still based on the purely-hypothetical format, while the boxes and their contents had changed. With this commit, they macros and corresponding parts that they create have been updated to represent the step-by-step data lineage of this paper. Also, in the "tools-per-year" plot, the green line was brought ontop of the histogram to be more clear (especially when transparency isn't implemented properly in the conversion).
2020-06-17Better color for project branch in branching figureMohammad Akhlaghi-1/+1
Until now the color for the branching figure'e "project" branch was too close to the Derved project branch. With this commit, I am using a slightly darker shade of brown that is sufficiently differnet from the core Maneage branch and the derived project branch.
2020-06-17Text surrounding software acknowledgements as a configuration fileBoud Roukema-16/+130
Until now, the English texts that embeds the list of software to acknowledge in the paper was hard-wired into the low-level coding ('reproduce/software/shell/configure.sh' to be more specific). But this file is very low-level, thus discouraging users to modify this surrounding text. While the list of software packages can be considered to be 'data' and is fixed, the surrounding text to describe the lists is something the authors should decide on. Authors of a scientific research paper take responsibility for the full paper, including for the style of the acknowledgments, even if these may well evolve into some standard text. With this commit, authors who do *not* modify 'reproduce/software/config/acknowledge_software.sh' will have a default text, with only a minor English correction from earlier versions of Maneage. However, Authors choosing to use their own wording should be able to modify the text parameters in `reproduce/software/config/acknowledge_software.sh` in the obvious way. This is much more modular than asking project authors to go looking into the long and technical 'configure.sh' script. Systematic issues: the file `reproduce/software/config/acknowledge_software.sh` is an executable shell script, because it has to be called by `reproduce/software/shell/configure.sh`, which, in principle, does not yet have access to `GNU make` (if I understand the bootstrap sequence correctly). It is placed in `config/` rather than `shell/`, because the user will expect to find configuration files in `config/`, not in `shell/`. A possible alternative to avoid having a shell script as a configure file would be to let `reproduce/software/config/acknowledge_software.sh` appear to be a `make` file, but analyse it in `configure.sh` using `sed` to remove whitespace around `=`, and adding other hacks to switch from `make` syntax to `shell` syntax. However, this risks misleading the user, who will not know whether s/he should follow `make` conventions or `shell` conventions.
2020-06-17Security risk of LaTeX's -shell-escape option explained in commentBoud Roukema-0/+9
The 'pdflatex' program is used to build the default Maneage-branch paper. But since the default paper uses PGFPlots to build the figures within LaTeX as an external PDF, PGFPlots requires 'pdflatex' to be called with the '-shell-escape' option. Generally, this option can be considered as a security risk (in particular when 'pdflatex' is being run by an external LaTeX file: a malicious LaTeX writer may embed commands in the LaTeX source that will be executed on the host if this option is present). This is not too serious of an issue in Maneage, because when someone runs Maneage, they intentionally let it run many on their system. Hence if someone wants to exploit a host system, they can add the necessary commands long before 'pdflatex' is run. After all, all commands in Maneage are run with the calling user's permissions, hence they have access to many parts of the user's accounts. If someone is worried about security on a non-trusted Maneage project they should act the same as they do with any software: define a new user for it, and call it with that user (as a weak-level security), or run it in a virtual machine or container. However, since this option has been explicity mentioned as a security risk before, it helps if we have a comment explaining its usage in 'paper.mk'. With this commit, the concerned user will read a brief explanation and can read the brief discussion at [1] and possibly re-open the discussion or propose ways of mitigating the security risk(s). [1] https://savannah.nongnu.org/task/?15694
2020-06-17Software tarballs are downloaded even if not builtMohammad Akhlaghi-56/+36
Some low-level software aren't necessary on some operating systems, for example GCC can't be built on macOS, hence we don't build it and the GCC-only dependencies. Also, on GNU/Linux systems users could configure with '--host-cc' to avoid all the time it takes to build GCC when doing a fast test. Until now, in such cases not only was the software not installed, but the tarballs of the software were also not downloaded. Hence making the output of '--dist-software' incomplete (as in bug #58561). With this commit, we now import all the necessary tarballs, when the software isn't necessary for the particular system, it won't be built or cited, but its tarball will be present anyway, thus allowing the output of '--dist-software' to be complete.
2020-06-17New target --dist-software to package all necessary software tarballsMohammad Akhlaghi-6/+5
When publishing a project, it is necessary to also publish the source code of all necessary software of the project. We had recently added a new './project make' target called 'dist-software' for this job, but had forgotten to add it in the output of './project --help'! There was also a small bug inside of it that didn't allow the successful copying of the created tarball to the top project directory. With this commit, an explanation for this target has been added in the output of './project --help' and that bug has been fixed.
2020-06-17Corrected symbolic link to Gnuastro's configuration filesMohammad Akhlaghi-1/+1
Until now, when making the link to Gnuastro's configuration files, the 'configure.sh' script would incorrectly link to the old configuration directory under the 'reproduce/software' directory. With this commit, it is moved to the proper directory under 'reproduce/analysis'.
2020-06-16Imported recent improvements in Maneage, minor conflicts fixedMohammad Akhlaghi-30/+56
Some minor conflicts came up in 'download.mk' and 'verify.mk' (as expected in the "IMPORTANT" commits) and were easily fixed by choosing this branch's values.
2020-06-16Using type to see if pdftotext exists or notMohammad Akhlaghi-1/+1
Until now we were using 'which' for this job, but throughout Maneage, we have used 'type', so to help in consistancy, we also use 'type' for this final command for this project also.
2020-06-16XLSX I/O properly accounts for local buildMohammad Akhlaghi-2/+2
Until now, when adding the necessary library flags to the build of XLSX I/O, we were effectively over-writing the 'LDFLAGS' variables. So the compiler was effectively not being told where to look for the necessary libraries. With this commit, to fix the problem, we now append the new linking flags to LDFLAGS in XLSX I/O's build, not over-write it.
2020-06-16Acknowledged contributions of Marios KarouzosMohammad Akhlaghi-31/+36
Marios had read the first draft of the paper (Commit f990bba) and provided valuable feedback (shown below) that ultimately helped in the current version. But because of all the work that was necessary in those days, I forgot to actually thank him in the acknowledgment, while I had implemented most of his thoughts. Following Marios' thoughts on the Git branching figure, with this commit, I am also adding a few sentences at the end of the caption with a very rough summary of Git. I also changed the branch commit-colors to shades of brown (incrementally becoming lighter as higher-level branches are shown) to avoid the confusion with the blue and green signs within the schematic papers shown in the figure. Marios' comments (April 28th, 2020, on Commit f990bba) ------------------------------------------------------ I think the structure of the paper is more or less fine. There are two places that I thought could be improved: 1) Section 3 (Principles) was somewhat confusing to me in the way that it was structured. I think the main source of confusion is the mixing of what Maeage is about and what other programs have done. I would suggest to separate the two. I would have short intro for the section, similar to what you have now. However, I would suggest to highlight the underlying goals motivating the principles that follow: reproducibility, open science, something else? Then I would go into the details of the seven principles. Some of the principles are less clear to me than others. For example, why is simplicity a guiding principle? Then some other principles appear to be related, for example modularity, minimal complexity and scalability to my eyes are not necessarily separate. Finally, I would separate the comparison with other software and either dedicate a section to that somewhere toward the end of the paper (perhaps a subsection for section 5) or at least condense it and put it as a closing paragraph for Section 3. As it is now I think it draws focus from Maneage and also includes some repetitions. 2) Section 4 (Maneage) was at times confusing because it is written, I think in part as a demonstration of Maneage (i.e., including examples that showed how Maneage was used to write this or other papers) and a manual/description of the software. I wonder whether these two aspects can be more cleanly separated. Perhaps it would be possible to first have a section 4 where each of the modules/units of Maneage are listed and explained and then have the following section discuss a working example of Maneage using this or another paper. 3) I found Figure 7 [the git branching figure] and its explanation not very intuitive. This probably has to do with my zero knowledge of github and how versioning there works, but perhaps the description can be a bit more "user friendly" even for those who are not familiar with the tool. 4) I find Section 6 to be rather inconsequential. It does not add anything and it more or less is just a summary of what was discussed. I would personally remove it and include a very short summary of the ideals/principles/goals of Maneage at the beginning of Section 5, before the discussion.
2020-06-15OpenSSL now built after PerlMohammad Akhlaghi-1/+1
After trying a clean build of Maneage in a Docker image (with a minimal debian:stable-20200607-slim OS), I noticed that the building of OpenSSL is failing because it doesn't find the proper Perl functionality. To fix it, with this commit, Perl is set as a prerequisite of OpenSSL and this fixed the problem.
2020-06-15Configure script now accounts for non-interactive shellsMohammad Akhlaghi-6/+33
The project configuration requires a build-directory at configuration time, two other directories can optionally be given to avoid downloading the project's necessary data and software. It is possible to give these three directories as command-line options, or by interactively giving them after running the configure script. Until now, when these directories weren't given as command-line options, and the running shell was non-interactive, the configure script would crash on the line trying to interactively read the user's given directories (the 'read' command). With this commit, all the 'read' commands for these three directories are now put within an 'if' statement. Therefore, when 'read' fails (the shell is non-interactive), instead of a quiet crash, a descriptive message is printed, telling the user that cause of the problem, and suggesting a fix. This bug was found by Michael R. Crusoe.