Ken Moffat wrote:
On Thu, May 21, 2015 at 06:10:02PM -0500, Bruce Dubbs wrote:
Douglas R. Reno wrote:
Hi all,
I need to have someone else's opinion about how to add the patch into
the instructions. Since it needs configure.ac, autoreconf -fiv must be
run to regenerate configure, eliminating the changes made by the
glibc-2.21 patch. Therefore, I need to know how to reorganize the page
to accommodate the patch. I would like some kind of recommendation on
how to restructure the page.
The real fix would be to patch configure.ac for the glibc-2.21 correction
and then run autoreconf. Since the linux_4.x_compilation_fix works on
configure.ac, the glibc fixes could also be merged into a consolidated
patch.
Agreed. Sometimes, we have taken an upstream configure.ac patch,
applied it, run autoreconf, and then created a new patch, edited
down to just configure. In this case, the opposite approach is
required.
Do you need help doing that?
Also in the patches, do NOT use embedded tabs (in patches or anything else
in BLFS). The valgrind-3.10.1-linux_4.x_compilation_fix-1.patch needs to be
redone to remove them.
$ cat /etc/vimrc
" Begin /root/.vimrc
set nocompatible
set backspace=2
syntax on
set expandtab
set tabstop=3
set shiftwidth=3
set laststatus=2
...
If an existing file already has tabs in it, the command in vim is :retab
assuming the above vimrc.
Bruce, I can see that you use tiny tab spacing in your own code, but
what is your objection to tabs in a patch ? If upstream uses tabs,
then tabs are the right thing for the patch. For a sed, spacing and
alignment are optional.
My objection to embedded taps is that different users have different settings
for tab stops. The files look a lot different if viewed in an editor and in a
cat. If spaces are used, then the file looks identical for everyone no matter
what tools are used.
At one time, the difference in spaces and tabs made a difference in file size.
Today, a few dozen bytes in the file size is quite negligible.
As far as small tab sizes go (indentation), there has been quite a bit of
research (admittedly old now), that says that the readability of source code is
optimal at 2-4 spaces for indentation. I split the difference and use 3.
Also, for indentation of fixed pitch fonts (for example 12 point monospaced) is
about 6 points or .083 inch. Indentation of 8 characters then is about 2/3
inch. In a printed text, how often do you see that much indention in printed
(paper) documents? Rarely because 1) it wastes space, and 2) because it
actually makes comprehension slower.
I don't have a good on-line reference. Most of what I see is opinion, but some
real research I have read are:
Baecker, R. and Marcus, M. Human Factores and Typography for More Readable
Programs, ACM Press/AddisonWesley, Reading MA, 1990.
Berry, R. and Meekings, B. A Style Anmalysis of C Programs. Communications of
the ACM 28, 1 (Jan 1985), 80-88.
Borenstein, N. Programming as if People Mattered. Princeton University Press,
Princeton, NJ, 1991.
Corbi, T. Program Understanding: Challenge for the 1990s. IBM systems Journal
28, 2 (Feb 1989), 294-306.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
