summaryrefslogtreecommitdiff
path: root/HACKING
blob: 5485a29b7da05508135a4fec143d2a336793cdba (plain)
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
All you need to know when hacking (modifying) GNU libunistring or when building
it off a git checkout.


Requirements
============

You will need reasonably recent versions of the build tools:

  * A C compiler. Such as GNU GCC.
    + Homepage:
      http://gcc.gnu.org/

  * GNU automake
    + Homepage:
      http://www.gnu.org/software/automake/

  * GNU autoconf
    + Homepage:
      http://www.gnu.org/software/autoconf/

  * GNU m4
    + Homepage:
      http://www.gnu.org/software/m4/

  * GNU gperf
    + Homepage:
      http://www.gnu.org/software/gperf/

  * GNU sed
    + Homepage:
      http://www.gnu.org/software/sed/

  * Perl
    + Homepage:
      http://www.perl.org/

  * Either an internet connection or a recent copy of GNU gnulib.
    In order to work with the HEAD of libunistring development, you need the
    HEAD of the gnulib development.
    In order to work with the version of libunistring at a given date, you need
    the version of gnulib of the same date.
    In order to work with a released tarball of libunistring, you need the
    particular version of gnulib which is indicated in the GNULIB_GIT_COMMIT
    variable in version.sh.
    + Homepage:
      http://www.gnu.org/software/gnulib/

And, of course, the packages listed in the DEPENDENCIES file.

Then you can run the 'autogen.sh' script 


Sources
=======

Most of the sources have their origin in gnulib.


Building
========

See the INSTALL file for generic instructions.

You can use the configure option --disable-namespacing to speed up the build
by a factor of 1.5.  The resulting library is not namespace-clean and
therefore should not be installed (if you don't want to risk collisions
with other libraries) and should certainly not be distributed.


Running the testsuite in valgrind
=================================

To run the test suite with a memory access checker and leak detector such as
valgrind,
  1) configure with the options --disable-shared and CFLAGS="-g",
  2) run "make",
  3) edit tests/Makefile to uncomment the appropriate definition of the CHECKER
     macro,
  4) run "make check".