| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Managing this symbolic link as a prerequisite that may or maynot be defined
just made the code too dirty. It is almost always needed, so it is now a
super-high-level prerequisite (first dependency of the `all' target, even
before the final PDF). In this way, we can be sure it is always built and
that nothing else depends on it.
If the user doesn't want it, they can simply remove it from the top
`Makefile'.
|
|
The choice of whether or not to make a PDF is now also a local system
issue, not a general pipeline issue. So it has been put in the new
`LOCAL.mk.in' file which replaces the old `DIRECTORIES.mk.in'. All local
settings (things that when changed should not be version-controlled) should
be defined in this file.
A sanity check was added to find if `./configure' has been run before
`make' or not (using the `LOCAL.mk' file which is an output of the
configuration step). If `LOCAL.mk' doesn't exist, an error will be printed
informing the user that `./configure' needs to be run first.
The configure script also provides more clear and hopefully better
information on its purpose and what must be done.
Since `make clean', it is executed even when `./configure' hasn't been run,
it will only delete the build directory and its contents when local
configuration has been done.
A `distclean' target was also added which will first "clean" the pipeline,
then delete the `LOCAL.mk.in' file.
To allow rules like `make' to be run even if `BDIR' isn't defined
(`./configure' hasn't been run yet), a fake `BDIR' is defined in such
cases.
|
|
While going over parts of the text, some minor typos were found and
corrected.
|
|
The title "Tips on using the pipeline" was a little generic and could be
confused with people who want to reproduce the result, not the designers of
the pipeline. So it was changed to "Tips on expanding this template
(designing your pipeline)". Some minor edits were also made to its first
paragraph.
|
|
Some minor typos were found and corrected. In other cases, the text was
slightly edited to be more clear.
|
|
Recently the filename keeping TeX macros for the versions was changed from
`versions.tex' to `initialization.tex' (since it also contained the build
directory). However, it was forgotten to correct the change of name in the
`.PHONY' targets, so it was not being rebuilt every time. This is corrected
now.
|
|
`README.md' is for this pipeline, not the research project that is using
it. Therefore it might be confused with the `README' that is devoted to the
research project. So in the checklist, a point was added to delete this
file before making the first new commit.
|
|
The README file didn't match the current way to set the top-level
directories (through `./configure'), it was still the old-fashioned way of
manually finding and opening the file. The explanation is now corrected.
|
|
The basic title, short description and author section of the checklist was
moved immediately after copyright because it is more related to it. The
description of Gnuastro is now before `README' because the user will
confront Gnuastro in `README' and this will provide a good introduction on
what to do with it.
|
|
The creation of a new Git repo is now moved to the end of the checklist. It
was not in place as the third step before. Now, the user makes all the
standard changes and just before they start going into the details of their
research, they define their new repository.
|
|
The description of adding a title and authors was made slightly more clear.
|
|
The first commit didn't have an explanation on correcting the title of the
project in the final PDF or the top-level Makefile, so a pointer was added
to the list. Also, some extra dependencies were removed from `README' and
its paragraphs were scaled to the new width of 75 characters that is
defined in `.dir-locals.el' (for Emacs settings, taken from Gnuastro).
|
|
Let's start working on this pipeline independently with this first
commit. It is based on my previous experiences, but I had never made a
skeleton of a pipeline before, it was always within a working analysis.
But now that the pipeline has a separate repository for its self, we will
be able to work on it and use it as a base for future work and modify it to
make it even better. Hopefully in time (and with the help of others), it
will grow and become much more robust and useful.
|
