| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Until now customizing it was a little more detailed, for example the
copyright statement wasn't generic and was about "this template". So the
user would have to correct it.
With this commit, the copyright statment just says "this project", so it
can apply to the raw template and also any customization of it. Also, some
minor edits were made in the various parts of the text to make it more
clear.
|
|
The Copyright year is now on a separate line (by adding a backslash), and
the `file-metadata' is now enclosed in two "`" characters to show
differently after rendering.
|
|
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.
|
|
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.
|
|
Since `.file-metadata' is a binary file, we can't include a copyright
inside of it so we have to use `README.md' to mention its copyright and
license notice. However, this was not done clearly and is now corrected.
|
|
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.
|
|
Since `.file-metadata' is a binary file and we couldn't put a copyright
notice within it, it has been mentioned in `README.md' to have the same
copyright.
Also, the copyright modification step in `README-hacking.md' was brought to
a later step to be more clear that it should always be done (on new files
or files that are changed).
|
|
Until now, for short files, we only had a license notice, not an actual
copyright notice. With this commit, a copyright notice has also been
added. We use this new command to find these files, suggested by
`ineiev@gnu.org'.
|
|
In order to be more clear, a copyright statement was added to all the LaTeX
and README files.
|
|
To be more generic and recognizable, the `README-pipeline.md' script was
renamed to `README-hacking.md'. In essence, it is just that: to hack the
existing pipeline for your own project. We follow a similar naming
convention in many GNU software.
|
|
Until now, there was no reference to `README-pipeline.md' within the
`README.md' file. Since `README.md' is the first file that someone reads
and the basic perpose and structure of the pipeline is described in
`README-pipeline.md', it was necessary to bring it up there.
|
|
To help and be more clear a link to this pipeline's dependency repository
has been added to `README.md'.
|
|
The README.md file was updated to reflect recent changes in the pipeline
(especially regarding the downloader).
|
|
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).
|
|
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.
|
|
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'.
|
|
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).
|
|
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).
|
|
The two README files have been updated to explain the new feature of
downloading and building dependencies.
|
|
All the used software are now acknowledged in the template paper along with
their versions. This section is also mentioned in the check list, so users
don't delete it by mistake.
|
|
The version of all programs is now checked in
`reproduce/make/src/initialize.mk' and the pipeline won't complete if any
of the program versions change from those listed in
`reproduce/config/pipeline/dependency-versions.mk'.
Since the pipeline is systematically checking all program versions, we
don't need Gnuastro's `--onlyversion' option any more. So it (and all
references to it) have been removed.
|
|
To enable easy/proper reproduction of results, all the high-level
dependencies are now built within the pipeline and installed in a fixed
directory that is added to the PATH of the Makefile. This includes GNU Bash
and GNU Make, which are then used to run the pipeline.
The `./configure' script will first build Bash and Make within itself, then
it will build
All the dependencies are also built to be static. So after they are built,
changing of the system's low-level libraries (like C library) won't change
the tarballs.
Currently the C library and C compiler aren't built within the pipeline,
but we'll hopefully add them to the build process also.
With this change, we now have full control of the shell and Make that will
be used in the pipeline, so we can safely remove some of the generalities
we had before.
|
|
After a full trial of the checklist, some further minor edits were made to
make it more clear.
|
|
Some minor changes were made to be more clear.
|
|
A few minor points were corrected in README.md.
|
|
A step was added close to the top of the checklist to remind people to
check the pipeline before making any changes. Also, the `--origin' option
was removed from the `git clone' command into a separate command to rename
the origin branch. This helps in readability.
|
|
Until now, in the check list of `README.md', we were recommending to delete
the history of the pipeline and start your own history from that. But this
disables users of the pipeline to keep it up to date with new features that
are added to it.
With this commit, the main branch is now called `pipeline' (to allow users
to use `master' for their own research) and in the clone command, the
pipeline's remote is now called `pipeline-origin' (to allow the user to use
`origin' for their own remote).
|
|
While trying the checklist, I noticed that I had forgot to add my name
after the copyright year and that `reproduce/src/make/paper.mk' still had
my own name on it, the copyright notice also said `script' instead of
`Makefile' which is now corrected.
|
|
While testing the reproduction pipeline on a small project, I noticed some
parts of the checklist that were either repetative or needed to be
corrected. This is done with this commit.
|
|
In the previous commit, ` was mistakenly written as '. This was only
noticed after pushing and rendering the Markup on the webpage.
|
|
A minor edit was made in the copyright correction part of the checklist.
|
|
To be more generic (and avoid listing file names in `README.md'), a command
is now used to find the files where the name has to be added to the
copyright notice. Also, I noticed that `reproduce/src/make/paper.mk' lacked
a placeholder name/email, so one was added.
|
|
Previously we had tried to corrected the problem that `.mk' files use space
instead of TAB by setting them to be read into makefile-mode at the
start. However, for some reason, this caused a problem in reading the
maximum line length (the value of 75 wasn't read by Emacs).
So after some playing around, I found out that the problem is that the
`nil' setting (for all other files) must be defined in the end, not the
start of the basic settings and this solved this problem.
|
|
Going through the text, some further minor edits were made.
|
|
Some minor edits to the newly added parts of `README.md'.
|
|
A section was added to `README.md' for describing possible future steps
that we can take to make this pipeline even more robust. In it, I added a
first interesting thing that I think would be really exciting to add, but I
don't have time to do now.
|
|
The link to the slides describing the context was the old address (which
still works, but is just a symbolic link to the new address). It was thus
corrected to point to the proper filename.
|
|
The main online repository name has been changed to `reproducible-paper'
from `reproduction-pipeline-template'. So the cloning command in
`README.md' had to be corrected.
|
|
Some minor corrections were made regarding the output repository.
|
|
The markup for the link to the final PDF in the `README.md' file was
mistakenly written and is now corrected.
|
|
A template was made to keep the output of this pipeline as a demonstration
and it is now added to the description in `README.md'.
|
|
While doing my own project (which has grown to a processing time of about
half an hour), I felt that it would be very convenient to a record of the
outputs at major points also. But we don't want to bloat the pipeline by
commiting PDF files or large datasets that get fully changed and are just
by-products. So it occurred to me to have a separate pipeline only for
outputs and after trying it out, it indeed seemds to be a good solution.
|
