| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Until now, to work on a project, it was necessary to `./configure' it and
build the software. Then we had to run `.local/bin/make' to run the project
and do the analysis every time. If the project was a shared project between
many users on a large server, it was necessary to call the `./for-group'
script.
This way of managing the project had a major problem: since the user
directly called the lower-level `./configure' or `.local/bin/make' it was
not possible to provide high-level control (for example limiting the
environment variables). This was especially noticed recently with a bug
that was related to environment variables (bug #56682).
With this commit, this problem is solved using a single script called
`project' in the top directory. To configure and build the project, users
can now run these commands:
$ ./project configure
$ ./project make
To work on the project with other users in a group these commands can be
used:
$ ./project configure --group=GROUPNAME
$ ./project make --group=GROUPNAME
The old options to both configure and make the project are still valid. Run
`./project --help' to see a list. For example:
$ ./project configure -e --host-cc
$ ./project make -j8
The old `configure' script has been moved to
`reproduce/software/bash/configure.sh' and is called by the new `./project'
script. The `./project' script now just manages the options, then passes
control to the `configure.sh' script. For the "make" step, it also reads
the options, then calls Make. So in the lower-level nothing has
changed. Only the `./project' script is now the single/direct user
interface of the project.
On a parallel note: as part of bug #56682, we also found out that on some
macOS systems, the `DYLD_LIBRARY_PATH' environment variable has to be set
to blank. This is no problem because RPATH is automatically set in macOS
and the executables and libraries contain the absolute address of the
libraries they should link with. But having `DYLD_LIBRARY_PATH' can
conflict with some low-level system libraries and cause very hard to debug
linking errors (like that reported in the bug report).
This fixes bug #56682.
|
|
The previous implementation of using shared memory to build software was
edited to be more clear and less prone to errors.
|
|
Until now, the template would unpack the software and build them directly
in the build directory of each project. After installation, the whole
unpacked directory is deleted. However, building the software involves the
reading and writing of millions of files, so on the long run, it can be bad
for the non-volatile memory (HDDs or SSDs), it can also be slightly slow.
To fix this, if the system has a shared-memory directory (commonly named
`/dev/shm'), we can do the temporary building of the software there. The
great thing about this unique directory is that it is actually in the RAM,
not on the HDD/SSD. This can slightly improve the speed (not much
probably), but more importantly it will not do any long-term harm to the
host's HDDs/SSDs.
With this commit, when there is a shared memory directory mounted in
`/dev/shm', and it has enough space (currently set to 2GB), the
`./configure' script will make `.build/software/build-tmp' as a symbolic
link to a fixed directory there. Otherwise, it will just build it as a
directory in the project's shared directory.
The structure has been defined in such a way that we can later easily add
different standard shared-memory locations (for different operating
systems).
This completes task #15336.
|
|
Configure script: when `texlive-ready-tlmgr' is not created, it is similar
to not having installed TeXLive. A check was added so in this scenario the
`./configure' script doesn't crash.
high-level.mk: `cairo' and `pixman' are now installed in parallel and with
`V=1' (so the full compilation and linking command is printed).
|
|
Until this commit, the addion of `-liconv' to `CXXFLAGS' in `high-level.mk'
dependend on `host_cc', but I had forgot that `host_cc' isn't defined for
`high-level.mk'. It is now defined for this Makefile also in the configure
script.
Also, the Standard C++ library depends on `libgcc_s.so.1', so after
building GCC, it was necessary to add Rpath to it.
|
|
To build the software, we need a C/C++ compiler. But until now at configure
time there was no check on this. As a result, when the system didn't have
them, the user would only learn in a crash of the programs.
With this commit, some checks have been added at configure time to do basic
checks and inform the user if necessary.
|
|
Several corrections were necessary in the basic build: 1) the
version of GCC on some systems includes an `_' which would cause
a crash when building the PDF. 2) libcharset had to be manually
added to the Git build.
|
|
With this commit, extra spaces in the definition of two variables in the
`configure' script have been removed. Since they are defined in a
`shell' context (not in `make'), variable assignation is not allow to
have any space at both sides of the `=' character. I detected these
typos when trying to run `./configure' in a particular project.
|
|
Until now, the `tex/build' symbolic link was put in the clone/source tree
when the build-directory's `tex' directory was being built. Thanks to
Roberto Baena, we just found a bug because of this behavior: when a second
group member is trying to build the pipeline, since the build directory's
`tex' directory already exists, no `tex/build' will be put in their
clone/source directory. As a result, the PDF building will crash.
To fix this (and keep things organized), the two `tex/build' and `tex/tikz'
links (to the build directory) are now built in the configure step while it
is building all the top-level directories. They are no longer built within
the Makefiles.
Also, a comment was added on top of every directory built during the
configuration phase to be clear.
This fixes bug #56362.
|
|
Especially because of the new convention regarding backslashes, there were
many conflicts that are now fixed. But none were substantial.
|
|
When we need to quote the new-line character we end the line with a
backslash (`\'). Until now, our convention has been to put all such
backslashes under each other to help in visual inspection.
But this causes a lot of confusion in version control: if only one line's
length is larger, the whole block will be marked as changed and thus makes
it hard to visually see the actual change. It also makes debuging the code
(adding some temporary lines) hard.
With this commit, I went through all the files and tried to fix all such
cases so only a single white space character is between the last command
character and the backslash. Where there was an empty line (ending with a
backslash, to help in visually separating the code into blocks), I put the
backslash right under the previous line's.
This completes task #15259.
|
|
Until now, to test if GCC can use `sys/cdefs.h', we were building
a small test program using it. But after testing on an Ubuntu 14.04,
we noticed that the GCC test during the configure script passes, but
GCC still can't be built. After some investigation we noticed its
available in other directories, but during the build of GCC, those
directories aren't used, and it only assumes it to be under
`/usr/include'. So with this commit, we are only checking this
particular location for this header, not a test run of GCC.
After fixing this, we noticed that GCC's build crashed again because
it couldn't link with `libc.a' (or `libc.so'). So we also added a
for this library and added a new warning to inform the user what they
might be able to do.
Finally, we noticed that in one of the last steps of building GCC,
we weren't using `&&', but `;', so the GCC name file would be
built, even when the GCC build failed.
|
|
Until now, to specify which high-level software you want the project to
contain, it was necessary to go into the `high-level.mk' Makefile that is
complicated and can create bugs.
With this commit, a new `reproduce/software/config/installation/TARGETS.mk'
file has been created that is easily/cleanly in charge of documenting the
final high-level software that must be built for the project.
Also, until now, FFTW was set as a dependency of Numpy while we couldn't
actually get Numpy to use it! It was just there for future reference and to
justify its build rule. But now that many software won't be built and there
is no problem with having rules even though a project might not use them,
it has been removed.
|
|
Until now, there were erros in the citation of Astrometry-net and Scamp
papers.
With this commit, we fix these problems. The Swarp bibtex has also been
modify to follow the stetic of the citation style we have right now in
the project.
We also added the `dependency-bib.tex' as a prerequisite of `paper.bbl'.
|
|
Until now, the software building and analysis steps of the pipeline were
intertwined. However, these steps (of how to build a software, and how to
use it) are logically completely independent.
Therefore with this commit, the pipeline now has a new architecture
(particularly in the `reproduce' directory) to emphasize this distinction:
The `reproduce' directory now has the two `software' and `analysis'
subdirectories and the respective parts of the previous architecture have
been broken up between these two based on their function. There is also no
more `src' directory. The `config' directory for software and analysis is
now mixed with the language-specific directories.
Also, some of the software versions were also updated after some checks
with their webpages.
This new architecture will allow much more focused work on each part of the
pipeline (to install the software and to run them for an analysis).
|
|
All occurances of "pipeline" have been chanaged to "project" or "template"
withint the text (comments, READMEs, and comments) of the template. The
main template branch is now also named `template'.
This was all because `pipeline' is too generic and couldn't be
distinguished from the base, and customized project.
|
|
Until now, the files where the people were meant to change didn't have a
proper copyright notice (for example `Copyright (C) YOUR NAME.'). This was
wrong because the license does not convey copyright ownership. So the name
of the file's original author must always be included and when people
modify it (and add their own copyright-able modifications).
With this commit, the file's original author (and email) are added to the
copyright notice and when more than one person modified a file, both names
have their individual copyright notice.
Based on this, the description for adding a copyright notice in
`README-hacking.md' has also been modified.
|
|
Until now, there was a single `tex/src/references.tex' file that housed the
BibTex entries for everything (software and non-software).
Since we have started to include the BibTeX entry for more software, it
will be hard to manage the large (sometime unused) BibTeX entries of the
software in the middle of the non-software related citations in the text of
the paper.
Therefore, with this commit, a `tex/dependencies' directory has been made
which has a separate BibTeX entry file for each software that needs
one. After the software is built, this file is copied to the new
`.local/version-info/cite' directory. At the end, the configure script will
concatenate all the files in this directory into one file which will later
be used with `tex/src/references.tex' by BibLaTeX.
This greatly simplifies managing of citations. Allowing us to focus on the
software-building and paper-writing citations separately/cleanly (and thus
be more efficient in both).
|
|
Until now, we hadn't actually tested the case where a whole software
directory (Python modules in particular) is empty. So the configure script
finished with some errors in this case.
With this commit, this step of the configure script was modified to deal
with such cases cleanly.
Also, in `initialize.mk', I added a `-f' to the symbolic link command, so
it doesn't complain if the file link already exists.
|
|
In order to get a consistent final result, in its later steps, the
configure script uses our own build of the basic command-line tools (like
`cat', `awk').
Also, a correction was made to the short option parsing errors when an
unwanted argument is given, and the `-?*' was changed to `-'?'*' to avoid
un-necessary shell interpretation (for example giving unreasonable
results).
|
|
On some systems, M4 isn't available, so the linking to the host system
fails, as a result, we can't build GNU Libtool.
The main reason we weren't building M4 was a bug with the most recent GNU C
library
(http://lists.gnu.org/archive/html/bug-gnulib/2019-04/msg00004.html). But I
found a patch used by Arch Linux which fixes the issue and allows M4 to be
built. As a result, the pipeline is now building M4 also and the patched M4
tarball is now uploaded to my own webpage as backup.
While doing the steps above, I also noticed that we weren't using a tab at
the start of the link definitions of `dependencies-basic.mk'. Although its
not necessary, to be consistent, its good for the lines to always start
with a tab.
|
|
The step where we check the possibility of using `sys/cdefs.h' was still
using `$$' for shell variables (in Make), not `$' (for the shell). This was
corrected.
Also, since Astropy needs two citations, the `,' in the citation command
would conflict with Make's parsing. So we just used an `echo' command to
re-write the version info.
In Astroquery, the prerequisite list was just reordered by length to be
more clear to the eye.
|
|
In some cases (specially when debugging the pipeline), its very
time-consuming to install GCC. With this commit, a `--host-cc' option has
been added to avoid building the C compiler when necessary.
The test to see if `sys/cdefs.h' is available on the system (necessary to
build GCC) has also been moved to the configure script to print a more
visible warning and also use the new `host_cc' variable to let
`dependencies-basic.mk' know that GCC shouldn't be built.
Finally, we are having problems installing M4 from source, so it has been
set as a mandatory dependency.
|
|
Until now, management of the software names and versions in the paper was
done manually (a macro had to be defined in `initialize.mk', then used in
`paper.tex', so they had to be manually set in two places). Managing this
was not easy.
To fix this, with this commit, each software building rule's target is a
text file that contains its human-readable name and its version. In the
end, the configure script sorts them by their name and writes them into a
LaTeX input file that we can easily import as a file into the main paper.
|
|
Until now, these versions were written in each run. This was mainly
inherited from the old days of the pipeline, where we didn't know the
software on the host. But now that we have almost everything under control,
we can just write these LaTeX macros at the end of the configure script and
make `initialize.mk' simpler and also (very slightly!) speed-up/simplify
the processing.
|
|
Double quotes were placed around the checked values so they can have space
within them. Also, some checks were added for options that don't accept a
value.
|
|
Until now, the short options to the configure script needed a delimiter
(either white-space or an `=') between the name and value.
With this commit, for short options, it also accepts the value immediately
touching the option name.
Also, when trying to fine the absolute address of a given path, a check was
added to abort if it doesn't exist.
|
|
Until now we were (wrongly) assuming that the configure script's
`--existsing-conf' option takes a value, while this is not the case.
|
|
We were developing the build of Numpy and Scipy on Mac in a parallel thread
and things seems to be working relatively nice now. There were only two
problems:
1) GCC still has some random building issues on Mac.
2) ATLAS shared libraries can't be built on Mac (so we used OpenBLAS to
build Numpy and Scipy on both Mac and GNU/Linux).
But for now, none of these problems are critical. So, we can progress in
one branch.
There were only very minor conflicts in the merge.
|
|
Until now, the steps to manage the command-line options of the configure
script were limited (couldn't accept an equal sign or space between the
option name and value). With this commit, it can now also accept optional
equal signs between the option name and value. Thus not causing many
confusions.
Also, it is more logically consistent for the link to the build-directory
to be placed in the top directory (as a hidden file like `.local' until
now), and not as a visible directory like `reproduce/build' (which we used
until now). Therefore, with this commit, the link to easily access the
build-directory is `.build' in the top source directory.
Finally, because `minmapsize' is too specific to Gnuastro and has now been
given its default value at the start of the configure script, the
description for `minmapsize' has been removed (to not confuse users who
don't use Gnuastro). If anyone is familiar enough with Gnuastro to change
it, they already know it from its book.
|
|
Until this commit, the installation of all Python packages were
done in a separate Makefile.
With this commit, the pipeline install Python packages as part of the
hight level software. All Python packages rules them remain in a
separate Makefile, but this Makefile is included in the high level
dependency `reproduce/src/make/dependencies.mk'.
|
|
With the options, it is now possible to run the configure script more
easily after the initial run. The `--help' option provides a nice and
complete introduction along with a listing of the input options and the
`-j' option can be use to manually set the number of threads.
|
|
Until now, we were using `flock' (file-lock) for downloading the input
datasets in series. But we couldn't do this when downloading the software
tarballs because `flock' wasn't yet available. Generally, unlike
processing, downloading is much better done in series than in parallel.
To enable serial downloads of the software also, with this commit we are
installing `flock' in the configure script (not in a Makefile). As a
result, besides `flock', we can also benefit from the other good features
of the `reproduce/src/bash/download-multi-try' script *(for example
attempting download again after some time).
Some GNU mirrors may have problems at the time of download, so with this
commit, we are using the main GNU FTP server for GNU programs.
|
|
All dependencies for building astroquery package have been done.
Until nowthe Python dependencies were built in the same Makefile
as the high level libraries and programs. But, because astroquery
has many dependencies we split the Python and Python packages
installation in a new Makefile.
The installation of differents packages are done using Python and
not pip, because we found some problems when doing it with pip.
Apparently there are some interferences between the packages
installed by the pip of the system and the pip installed as part
of Python in the pipeline.
|
|
Until now, the group name to build the project actually went into the Git
source of the project! This doesn't allow exact reproducibility on
different machines (where the group name may be different).
With this commit, the `for-group' script has been modified to accept the
group name as its first argument and pass that onto `configure' and
Make. This is much better now, because not only the existance of a group
installation is checked, but also the name of the group. It also made
things simpler (in particular in `LOCAL.mk.in').
|
|
Until now, the `./configure' script would only print the `.local/bin/make
-j8' command. But when configured for groups, a different command should be
used. It now does a check just before running and suggests the proper
command.
|
|
Until now it was `/bin/sh', but on Debian systems, this can cause problems
because by default they use a much weaker shell (dash) which doesn't
recognize functions.
|
|
If the `./for-group' script is not used properly, it can lead to the whole
pipeline being re-run. Therefore it is important to do a sanity check
immediately at the start of Make's processing and inform the user if there
is a problem.
With this commit, `./for-group' exports the `reproducible_paper_for_group'
variable which is used by both the initial `./configure' script, and later
in each call to Make. The `./configure' script will use it to write a value
in `reproduce/config/pipeline/LOCAL.mk' and Make will use it to compare
with the value in `reproduce/config/pipeline/LOCAL.mk'.
If there is an inconsistency, Make will not even attempt to build anything
and will just print a message and abort.
|
|
Since the current implementation of this pipeline officially started in
2018, all the files only had 2018 in their copyright years. This has now
been corrected to 2018-2019.
|
|
To make things clear for a user of the pipeline its mentioned that the
given input directory is only read and nothing is written to it.
|
|
Some problems with using the number of threads in dependency building were
fixed.
|
|
Some host Make systems may not allow automatic passing of the number of
threads to sub-Makes. So while building the basic dependencies, we'll need
to explicity add the `-j' option to the Make files that can benefit most
from it: those that are dependencies of many others (Tar & Make), or are
the last to build (Coreutils).
|
|
The comment above the downloader section of the configure script was not up
to date with how the pipeline uses a downloader during configuration and
building now. So it was updated.
|
|
Until now we had constrained the configuration step to one thread to easily
see failures on other systems. But with most tests passing successfully
now, we are using the total number of available threads.
|
|
The build systems of Libgit2 and WCSLIB on Mac OS does not account for
installation in non-standard addresses: `Libgit2' keeps the absolute
address of its build directory (not the installation directory) and WCSLIB
doesn't write any absolute address at all (so the system uses the first one
it finds).
To address these issues, we are now using Mac OS's `install_name_tool'
program to fix the absolute path within the installed shared library.
Since the version of the library is actually present in its shared library
name, in `dependency-versions.mk' we have also separated these two
libraries so later when their version is changed, we are careful in
correcting the shared library name also.
|
|
OpenSSL can't automatically detect the architecture of Mac OS systems, so
as it suggests on its Wiki, it needs some help for doing that. With this
commit, we are checking the build on Mac OS with the presence of `otool'
(Mac OS's linker). If it's there, we'll add the OpenSSL configuration
options suggested by OpenSSL's Wiki.
|
|
Until now, we weren't including the `rpath' linking options to the basic
dependencies. They are now added. Also, when the download of an input file
fails for any reason, an empty file won't be replaced there any more.
|
|
To enable easy downloading of HTTPS links with Wget (this pipeline's defaut
downloader), we need a set of trusted CA certificates. Until the time that
we can generate one ourselves, one generic set of trusted CA certificates
is now downloaded like a tarball and placed in the OpenSSL configuration
directory.
With these CA certificates, within the pipeline we can now safely use the
pipeline's own installed Wget.
|
|
Some high-level programs like Wget and cURL need to be built in shared mode
because they also include dynamic loading of libraries. Therefore, if we
only build the lower-level libraries in static mode, our own build will be
ignored and they will go and find the system's shared libraries to link
with. Because of this, for now, we have manually set the `static_build'
variable in the configure script to `no'.
Also, if the downloader fails, we'll delete the output (an empty file in
the case of Wget) because it interefers with a target definition.
|
|
To help in debugging, we are only running the Makefiles within the
configure script on one thread.
|
