2009/12/11 Volker Grabsch
<address@hidden>
Tony Theodore <address@hidden> schrieb:
> I've made some small changes in the Makefile to put the log* and
> installed* files in their own directories, move the logs out of usr,
> and reduce the log size. This is mostly helpful for testing, but might
> be generally useful.
and installed* into separate sub directories, but I'm unsure of the
other proposals. In particular, I prefer to improve the defaults
rather than adding more variables and options.
1) moving logs out of usr
What is the purpose of that? In how far does it help testing?
If it's about saving disk space in usr/, there is already
"make strip" which strips the libraries, binaries and removes
much useless stuff from usr/, including the log files.
It's mostly to preserve the logs so I can see diffs between changes/systems/successful runs. Sometimes I copy the src directory into the log dir so I can see exactly what I changed and the change in output. Even without a "make clean", the log for the failing package is deleted if I don't remember to copy it out, which I was finding happened to me more often than not; so moving the logs out of usr into their own time-stamped dir made sense.
2) reducing the log size
This is mainly about the unpack command at the beginning, and
the last remove command at the end. These can clutter the interesting
stuff in between.
2a) verbose remove command at the end
This command provides valuable information. It shows
exactly which files were generated by the build. In
addition, you usually don't see that during testing,
because when the build fails at any point, nothing will
be removed, which allows for further investigation within
the tmp-PKG/ folder.
Could you explain in how far this is annoying for testing?
It's one of those ill-conceived micro-optimisations to save a few milliseconds on diff commands. I hadn't really thought about it, but I can see now that comparing the files generated by a successful build may help debugging errors later in the dependency chain (say binutils on Open Solaris that causes gcc to fail).
2b) verbose unpack command at the beginning
Here I see your point, as the verbosity doesn't add much
information. You get exactly the same information by
looking into the source tarball (e.g. with "mc" or "tar -tf").
In addition, that "log prefix" makes it hard to find the
initial ./configure command.
(... although it can be easily found by performing a search for
"./configure" or "\./configure", which is what I usually do.)
Another second or so, but I like to get to ./configure immediately. It matters less in vi, but now that I've discovered sshfs, I tend to open logs in a gui text editor and lazily scroll.
Maybe our testing workflows differ at some important point,
so it would be interesting to know why you find the points
1) and 2a) so annoying.
For now, I propose the following changes:
A) Move the installation markers and log files into sub folders:
usr/installed-PKG -> usr/installed/PKG
usr/log-PKG -> usr/log/PKG
B) Unpack archives quietly:
tar xv -> tar x
unzip -> unzip -q
Feel free to correct me if I'm wrong, i.e. if this isn't going
far enough for some reason.
That seems ideal; a prefix or extension on the logs/installation markers might be useful, but probably not worth discussing either way.
I'd still like to preserve logs across different builds, but there's no general use for this, and learning a little bit more about mercurial will make this easy.
Tony