-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathHACKING
161 lines (126 loc) · 5.7 KB
/
HACKING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
All you need to know when hacking (modifying) GNU gperf or when building
it off the git repository.
Requirements
============
You will need reasonably recent versions of the build tools:
* A C and a C++ compiler. Such as GNU GCC.
+ Homepage:
https://gcc.gnu.org/
+ Pre-built package name:
- On Debian and Debian-based systems: gcc, gcc-doc,
- On Red Hat distributions: gcc.
- Other: https://repology.org/project/gcc/versions
* GNU automake
+ Homepage:
https://www.gnu.org/software/automake/
+ Pre-built package name:
- On Debian and Debian-based systems: automake,
- On Red Hat distributions: automake.
- Other: https://repology.org/project/automake/versions
* GNU autoconf
+ Homepage:
https://www.gnu.org/software/autoconf/
+ Pre-built package name:
- On Debian and Debian-based systems: autoconf, autoconf-doc,
- On Red Hat distributions: autoconf.
- Other: https://repology.org/project/autoconf/versions
* GNU m4
+ Homepage:
https://www.gnu.org/software/m4/
+ Pre-built package name:
- On Debian and Debian-based systems: m4, m4-doc,
- On Red Hat distributions: m4.
- Other: https://repology.org/project/m4/versions
* GNU texinfo
+ Homepage:
https://www.gnu.org/software/texinfo/
+ Pre-built package name:
- On Debian and Debian-based systems: texinfo,
- On Red Hat distributions: texinfo.
- Other: https://repology.org/project/texinfo/versions
* Perl
+ Homepage:
https://www.perl.org/
+ Pre-built package name:
- On Debian and Debian-based systems: perl, perl-doc,
- On Red Hat distributions: perl.
- Other: https://repology.org/project/perl/versions
* TeX (for making the doc in .dvi, .ps or .pdf format)
+ Homepage:
https://tug.org/texlive/
+ Pre-built package name:
- On Debian and Debian-based systems: texlive-base, texlive-latex-base,
- On Red Hat distributions: texlive-base.
- Other: https://repology.org/project/texlive/versions
* Either an internet connection or a recent copy of GNU gnulib.
+ Homepage:
https://www.gnu.org/software/gnulib/
* GNU tar (for creating distributable tarballs)
+ Homepage:
https://www.gnu.org/software/tar/
+ Pre-built package name:
- On Debian and Debian-based systems: tar, tar-doc,
- On Red Hat distributions: tar.
- Other: https://repology.org/project/tar/versions
And, of course, the packages listed in the DEPENDENCIES file.
Building off the Git repository
===============================
Access to the Git repository is described at
https://savannah.gnu.org/git/?group=gperf .
After fetching the sources from the Git repository, peek at the comments in
autogen.sh, then run
./autopull.sh
./autogen.sh
Then you can proceed with "./configure" as usual.
Each time you want to update the source, do not only "git pull". Instead do
git pull && ./autopull.sh
./autogen.sh
Continuous integration
======================
The package is built automatically, at regular intervals. You find the latest
build results here:
https://gitlab.com/gnu-gperf/ci-distcheck/pipelines
https://gitlab.com/gnu-gperf/ci-distcheck/-/jobs?scope=finished
Submitting patches
==================
Patches should be sent to bug-gperf@gnu.org, the bug/feature mailing
list. You can subscribe to the mailing list, or see the list
archives, by following links from
https://savannah.gnu.org/mail/?group=gperf .
To email a patch you can use a shell command like 'git format-patch -1'
to create a file, and then attach the file to your email.
For the style of a ChangeLog entry, see the "Change Logs" section of
the GNU coding standards:
https://www.gnu.org/prep/standards/html_node/Change-Logs.html
Avoid use of the C++ Standard Library
=====================================
In this package, we avoid use of the C++ Standard Library, except for
low-level facilities that are tied with the C++ language (such as
placement-new or 'throw std::bad_alloc()'). The reasons are:
* My general experience with C++ is that the more features from
the language I use, the more it turns into a waste of time, and
I have the suspicion that with the C++ library it would be
the same.
* There are several implementations of the C++ Standard Library,
and I'm not inclined to start adding workarounds here and there,
like we did with C library bugs before Gnulib was invented.
* I hate bloat, and the C++ Standard Library is bloated. Even
if a large amount of this bloat goes away through inlining and
compiler optimizations, I hate to read through the x86_64 instructions
generated by the compiler in order to understand what a certain
piece of code actually does. (Reading the libstdc++ code is not
an alternative, because the abuse of templates in C++ — originally
invented for containers — makes that code unreadable. For
comparison, the D language has similar amounts of bloat as C++,
but it's at least halfway readable.)
* I hate to have duplicate code at the binary level. The C++ library
often instantiates the same code once for each set of template
parameters. Instead, I want to have control over which function
occurs only once.
* The C++ Standard Library does not evolve monotonically. Up until
C++11, they added things in backwards compatible ways. But when
you peruse cppreference.com, you realize that starting with C++17
they remove features [1] or reorganize features in non-backward-
compatible ways [2].
[1] https://lists.gnu.org/archive/html/bug-gnulib/2023-09/msg00054.html
[2] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/examples/hello-c%2B%2B20/hello.cc