| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Thanks to a test build on Raul Infante Sainz's Mac OS computer, we were
able to address some issues and will be trying them after this commit:
a) The LLVM linker on that computer didn't recognize `-rpath-link'! So at
configure time we now check for it and only include it when the linker
recognizes it.
b) CMake corrections: 1) `CMAKE_LIBRARY_PATH' is now defined so CMake can
look in our custom directory to find the necessary libraries. 2) To
build and install the CMake built programs, we now simply use `make'
and `make install'.
c) To avoid particular linking problems with WCSLIB (which has special
problems compared to other libraries), we are now deleting the shared
library version (both on GNU and Mac systems).
|
|
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.
|
|
Previously the SHELL environment variable was only set in `./configure',
`make', and `make install' after our internal Bash was installed. This
caused problems with Lzip's configure script on older shells (tested on a
Mac OS by Raul Infante Sainz).
So now, before having our own Bash, we set it to a possibly existing Bash
on the system and if that isn't present, just the standard `/bin/sh'.
|
|
The pipeline now installs GCC and all its necessary prerequisites.
|
|
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.
|
|
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.
|
|
We had forgot to add the rule to build the lock file directory for
downloading data. This has been corrected.
|
|
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.
|
|
While working on a research project using this pipeline, I noticed that we
don't have any `sh' executable within our PATH. However, some programs
(including Gnuastro's configure script, when it is checking for shells to
use with Libtool) check and use it. So after building Bash, we also build
an `sh' symbolic link to point to the built Bash executable.
|
|
To avoid redundant steps in the the top-level Makefile and make it simpler
and easier to follow, we now define the base names of all the Makefiles in
the `makesrc' variable of the top-level Makefile. `makesrc' is then used to
define the Makefiles to include and the necessary TeX macros at the same
time. This is much more clear and obvious than the previous case were we
had to list the Makefiles and TeX macro files separately in the top level
Makefile.
|
|
Until now, we were keeping the input file within the reproduction
pipeline's directories using the same name as the database/server. Now, we
are using a short/summarized filename convention for the input dataset.
|
|
While preparing the input dataset downloading scripts, we wanted to have
two input datasets, but it was too much, so it was ultimately removed. But
I had forgot to remove the information about this file in the `./configure'
script. So it is removed now.
|
|
A step has been added to the checklist to correct the template's input
dataset into the custom dataset necessary for each research.
|
|
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.
|
|
There was an extra line (probably created by Emacs in a wrong command!) in
the end of `README-pipeline.md' that has been removed.
|
|
A spellcheck was run on the two README files.
|
|
The note to the pipeline designers was corrected to display properly on
Gitlab.
|
|
A placeholder link is now used in `README.md' to encourage the pipeline
designers to keep a backup of all the dependencies they use.
|
|
Until now, were were advising the users to rename the two README files
after cloning the project. This was because online Git browsers usually
display the `README.md' file, so we wanted the description of the pipeline
to be visible in the pipeline, and later when a project adopts it, they can
have their own `README.md'. But the problem is that any change in
`REAME.md' will later cause conflicts with a project's `README.md'. So we
are now using the same naming convention as the papers that use the
pipeline.
|
|
In the checklist, we are now defining the remote host of the repository at
an early stage. This is because we will need it in the `README.md' file
(which now has a placeholder `XXXXXXX' instead of a valid URL).
|
|
The README file was edited to be more clear and easy to understand. In
particular, it is explained that Git is not necessary for getting the
pipeline.
|
|
Until now, in the instructions, we were suggesting to run
`./.local/bin/make', but the `./' part is extra: this is already a
directory and so the shell will be able to find it. So to make things more
clear and easy to read/write, we removed the `./' part from the calls to
our custom Make installation.
|
|
By default, Wget uses the same time stamp for the downloaded file as the
server. As a result, if a dependency was previously built before the
tarball was uploaded to the server, the pipeline wouldn't recognize that
its new and wouldn't re-build it. With this commit, we are adding the
`--no-use-server-timestamps' to the call to Wget to fix this problem.
I also noticed that (probably as a bug left over from the time we were
testing the configure script), we were manually setting the `userread'
variable to `n' independent of what the user provided. This has also been
fixed.
|
|
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.
|
|
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'.
|
|
In the previous commit, we were recommending to fetch the work from this
pipeline. But since we have a separate `pipeline' branch, we can simply
checkout to that branch and pull all the recent changes. So with this
commit, the steps to get recent updates to the pipeline are updated.
|
|
Since working on the pipeline will evolve along with the projects that use
it, it can be useful for projects to fetch updates in the pipeline. So the
checklist in `README.md' updated to explain how to do this cleanly.
|
|
Until now, because we didn't build the dependencies internally, it was
important for the pipeline to be usable with any version of Make. But
because of the new installation of dependencies (including GNU Make), that
is no longer the case. So we can safely use GNU Make and this needs to be
mentioned in `README.md'.
|
|
Gnuastro is just one of the softwares used in the pipeline, so it is too
much to include its version just under the abstract. However, the version
of the pipeline is very important as well as the link to it. This change
puts more emphasis on these two more important points.
|
|
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.
|
|
After installing the basic dependencies, we have access to the internally
built `nproc' program (by Coreutils) to find the number of threads we can
use for building the high-level batch of dependencies. Unfortunately, I had
added an extra `./' before `$instdir' when calling `nproc' so the script
failed. This problem is fixed now.
|
|
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!).
|
|
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).
|
|
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.
|
|
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.
|
|
After going through the checklist for starting a new project based on the
pipeline, I noticed some parts that could be modified to be more
clear. They are now applied.
|
|
Until now, we were using a customized `tar.lz' tarball for Gzip. But on
systems that don't have GNU Tar, this will cause a problem (non-GNU Tar
doesn't recognize `.tar.lz'). So to keep things simple, we are using the
customized gzip in `tar.gz' format. After the internal build of GNU Tar and
Lzip, the default method of unpacking (`tar xf XXXXX.tar.XX') will work
nicely on all the standard compression algorithms and we don't have to
modify our commands based on the algorithm (nice feature of GNU Tar).
|
|
To help in debugging on other systems, the building of dependencies is only
done on a single thread.
|
|
The two README files have been updated to explain the new feature of
downloading and building dependencies.
|
|
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.
|
|
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.
|
|
In the previous commit, for testing the static build, I had added a
`-ljunk' option to the compiler. But I had forgot to remove it! It is
removed now.
|
|
If the Makefile `$(static_build)' variable in
'/reproduce/src/make/dependencies-build-rules.mk' isn't defined (by
mistake), it will default to blank space, then the Shell will complain
about a bad formatted operator (needing two operands). So an `x' was added
before it and before `yes' which will allow us to safely pass such cases
without a terrible crash.
|
|
The default Mac compiler has problems building static libraries. Since we
are not yet building the GNU C Compiler as part of the pipeline, we'll have
to rely on the host system's compiler. Therefore, a check is now added a
the start of the configure script that will build a minimal program with
the `-static' flag and if it fails, it will print a warning. Afterwards,
none of the dependencies will be built with the `-static' flag.
|
|
Some minor corrections have been made in the paper's text to make things
easier to read and be more formal.
|
|
A semi-colon was missed in defining the link for `zlib'. It is now added.
|
|
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.
|
|
Until now, when a package was to be built statically, we were adding the
`--static' option to `CFLAGS'. This was the wrong place to put it! It
should be in the linking step (thus `LDFLAGS'). Also, based on Bash's
configure script, we are now using the more generic form of `-static'
(single dash, not double dash).
On the other hand, the `--disable-shared' option isn't available in many of
the packages and it is highly redundant with the `-static' option, so it
has been removed to avoid an extra warning in such packages.
|
|
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.
|
|
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.
|
