/
hda000000087.bin
1353 lines (1105 loc) · 64 KB
/
hda000000087.bin
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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
aries. It is much cleaner to make other data files
architecture-independent, and it is generally not hard.
Here are the variables Makefiles should use to specify directories
to put these various kinds of files in:
`datarootdir'
The root of the directory tree for read-only
architecture-independent data files. This should normally be
`/usr/local/share', but write it as `$(prefix)/share'. (If you
are using Autoconf, write it as `@datarootdir@'.) `datadir''s
default value is based on this variable; so are `infodir',
`mandir', and others.
`datadir'
The directory for installing idiosyncratic read-only
architecture-independent data files for this program. This is
usually the same place as `datarootdir', but we use the two
separate variables so that you can move these program-specific
files without altering the location for Info files, man pages, etc.
This should normally be `/usr/local/share', but write it as
`$(datarootdir)'. (If you are using Autoconf, write it as
`@datadir@'.)
The definition of `datadir' is the same for all packages, so you
should install your data in a subdirectory thereof. Most packages
install their data under `$(datadir)/PACKAGE-NAME/'.
`sysconfdir'
The directory for installing read-only data files that pertain to a
single machine-that is to say, files for configuring a host.
Mailer and network configuration files, `/etc/passwd', and so
forth belong here. All the files in this directory should be
ordinary ASCII text files. This directory should normally be
`/usr/local/etc', but write it as `$(prefix)/etc'. (If you are
using Autoconf, write it as `@sysconfdir@'.)
Do not install executables here in this directory (they probably
belong in `$(libexecdir)' or `$(sbindir)'). Also do not install
files that are modified in the normal course of their use (programs
whose purpose is to change the configuration of the system
excluded). Those probably belong in `$(localstatedir)'.
`sharedstatedir'
The directory for installing architecture-independent data files
which the programs modify while they run. This should normally be
`/usr/local/com', but write it as `$(prefix)/com'. (If you are
using Autoconf, write it as `@sharedstatedir@'.)
`localstatedir'
The directory for installing data files which the programs modify
while they run, and that pertain to one specific machine. Users
should never need to modify files in this directory to configure
the package's operation; put such configuration information in
separate files that go in `$(datadir)' or `$(sysconfdir)'.
`$(localstatedir)' should normally be `/usr/local/var', but write
it as `$(prefix)/var'. (If you are using Autoconf, write it as
`@localstatedir@'.)
These variables specify the directory for installing certain specific
types of files, if your program has them. Every GNU package should
have Info files, so every program needs `infodir', but not all need
`libdir' or `lispdir'.
`includedir'
The directory for installing header files to be included by user
programs with the C `#include' preprocessor directive. This
should normally be `/usr/local/include', but write it as
`$(prefix)/include'. (If you are using Autoconf, write it as
`@includedir@'.)
Most compilers other than GCC do not look for header files in
directory `/usr/local/include'. So installing the header files
this way is only useful with GCC. Sometimes this is not a problem
because some libraries are only really intended to work with GCC.
But some libraries are intended to work with other compilers.
They should install their header files in two places, one
specified by `includedir' and one specified by `oldincludedir'.
`oldincludedir'
The directory for installing `#include' header files for use with
compilers other than GCC. This should normally be `/usr/include'.
(If you are using Autoconf, you can write it as `@oldincludedir@'.)
The Makefile commands should check whether the value of
`oldincludedir' is empty. If it is, they should not try to use
it; they should cancel the second installation of the header files.
A package should not replace an existing header in this directory
unless the header came from the same package. Thus, if your Foo
package provides a header file `foo.h', then it should install the
header file in the `oldincludedir' directory if either (1) there
is no `foo.h' there or (2) the `foo.h' that exists came from the
Foo package.
To tell whether `foo.h' came from the Foo package, put a magic
string in the file--part of a comment--and `grep' for that string.
`docdir'
The directory for installing documentation files (other than Info)
for this package. By default, it should be
`/usr/local/share/doc/YOURPKG', but it should be written as
`$(datarootdir)/doc/YOURPKG'. (If you are using Autoconf, write
it as `@docdir@'.) The YOURPKG subdirectory, which may include a
version number, prevents collisions among files with common names,
such as `README'.
`infodir'
The directory for installing the Info files for this package. By
default, it should be `/usr/local/share/info', but it should be
written as `$(datarootdir)/info'. (If you are using Autoconf,
write it as `@infodir@'.) `infodir' is separate from `docdir' for
compatibility with existing practice.
`htmldir'
`dvidir'
`pdfdir'
`psdir'
Directories for installing documentation files in the particular
format. They should all be set to `$(docdir)' by default. (If
you are using Autoconf, write them as `@htmldir@', `@dvidir@',
etc.) Packages which supply several translations of their
documentation should install them in `$(htmldir)/'LL,
`$(pdfdir)/'LL, etc. where LL is a locale abbreviation such as
`en' or `pt_BR'.
`libdir'
The directory for object files and libraries of object code. Do
not install executables here, they probably ought to go in
`$(libexecdir)' instead. The value of `libdir' should normally be
`/usr/local/lib', but write it as `$(exec_prefix)/lib'. (If you
are using Autoconf, write it as `@libdir@'.)
`lispdir'
The directory for installing any Emacs Lisp files in this package.
By default, it should be `/usr/local/share/emacs/site-lisp', but
it should be written as `$(datarootdir)/emacs/site-lisp'.
If you are using Autoconf, write the default as `@lispdir@'. In
order to make `@lispdir@' work, you need the following lines in
your `configure.in' file:
lispdir='${datarootdir}/emacs/site-lisp'
AC_SUBST(lispdir)
`localedir'
The directory for installing locale-specific message catalogs for
this package. By default, it should be `/usr/local/share/locale',
but it should be written as `$(datarootdir)/locale'. (If you are
using Autoconf, write it as `@localedir@'.) This directory
usually has a subdirectory per locale.
Unix-style man pages are installed in one of the following:
`mandir'
The top-level directory for installing the man pages (if any) for
this package. It will normally be `/usr/local/share/man', but you
should write it as `$(datarootdir)/man'. (If you are using
Autoconf, write it as `@mandir@'.)
`man1dir'
The directory for installing section 1 man pages. Write it as
`$(mandir)/man1'.
`man2dir'
The directory for installing section 2 man pages. Write it as
`$(mandir)/man2'
`...'
*Don't make the primary documentation for any GNU software be a
man page. Write a manual in Texinfo instead. Man pages are just
for the sake of people running GNU software on Unix, which is a
secondary application only.*
`manext'
The file name extension for the installed man page. This should
contain a period followed by the appropriate digit; it should
normally be `.1'.
`man1ext'
The file name extension for installed section 1 man pages.
`man2ext'
The file name extension for installed section 2 man pages.
`...'
Use these names instead of `manext' if the package needs to
install man pages in more than one section of the manual.
And finally, you should set the following variable:
`srcdir'
The directory for the sources being compiled. The value of this
variable is normally inserted by the `configure' shell script.
(If you are using Autoconf, use `srcdir = @srcdir@'.)
For example:
# Common prefix for installation directories.
# NOTE: This directory must exist when you start the install.
prefix = /usr/local
datarootdir = $(prefix)/share
datadir = $(datarootdir)
exec_prefix = $(prefix)
# Where to put the executable for the command `gcc'.
bindir = $(exec_prefix)/bin
# Where to put the directories used by the compiler.
libexecdir = $(exec_prefix)/libexec
# Where to put the Info files.
infodir = $(datarootdir)/info
If your program installs a large number of files into one of the
standard user-specified directories, it might be useful to group them
into a subdirectory particular to that program. If you do this, you
should write the `install' rule to create these subdirectories.
Do not expect the user to include the subdirectory name in the value
of any of the variables listed above. The idea of having a uniform set
of variable names for installation directories is to enable the user to
specify the exact same values for several different GNU packages. In
order for this to be useful, all the packages must be designed so that
they will work sensibly when the user does so.
At times, not all of these variables may be implemented in the
current release of Autoconf and/or Automake; but as of Autoconf 2.60, we
believe all of them are. When any are missing, the descriptions here
serve as specifications for what Autoconf will implement. As a
programmer, you can either use a development version of Autoconf or
avoid using these variables until a stable release is made which
supports them.
File: standards.info, Node: Standard Targets, Next: Install Command Categories, Prev: Directory Variables, Up: Makefile Conventions
7.2.6 Standard Targets for Users
--------------------------------
All GNU programs should have the following targets in their Makefiles:
`all'
Compile the entire program. This should be the default target.
This target need not rebuild any documentation files; Info files
should normally be included in the distribution, and DVI (and other
documentation format) files should be made only when explicitly
asked for.
By default, the Make rules should compile and link with `-g', so
that executable programs have debugging symbols. Users who don't
mind being helpless can strip the executables later if they wish.
`install'
Compile the program and copy the executables, libraries, and so on
to the file names where they should reside for actual use. If
there is a simple test to verify that a program is properly
installed, this target should run that test.
Do not strip executables when installing them. Devil-may-care
users can use the `install-strip' target to do that.
If possible, write the `install' target rule so that it does not
modify anything in the directory where the program was built,
provided `make all' has just been done. This is convenient for
building the program under one user name and installing it under
another.
The commands should create all the directories in which files are
to be installed, if they don't already exist. This includes the
directories specified as the values of the variables `prefix' and
`exec_prefix', as well as all subdirectories that are needed. One
way to do this is by means of an `installdirs' target as described
below.
Use `-' before any command for installing a man page, so that
`make' will ignore any errors. This is in case there are systems
that don't have the Unix man page documentation system installed.
The way to install Info files is to copy them into `$(infodir)'
with `$(INSTALL_DATA)' (*note Command Variables::), and then run
the `install-info' program if it is present. `install-info' is a
program that edits the Info `dir' file to add or update the menu
entry for the given Info file; it is part of the Texinfo package.
Here is a sample rule to install an Info file:
$(DESTDIR)$(infodir)/foo.info: foo.info
$(POST_INSTALL)
# There may be a newer info file in . than in srcdir.
-if test -f foo.info; then d=.; \
else d=$(srcdir); fi; \
$(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@; \
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
# We use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
if $(SHELL) -c 'install-info --version' \
>/dev/null 2>&1; then \
install-info --dir-file=$(DESTDIR)$(infodir)/dir \
$(DESTDIR)$(infodir)/foo.info; \
else true; fi
When writing the `install' target, you must classify all the
commands into three categories: normal ones, "pre-installation"
commands and "post-installation" commands. *Note Install Command
Categories::.
`install-html'
`install-dvi'
`install-pdf'
`install-ps'
These targets install documentation in formats other than Info;
they're intended to be called explicitly by the person installing
the package, if that format is desired. GNU prefers Info files,
so these must be installed by the `install' target.
When you have many documentation files to install, we recommend
that you avoid collisions and clutter by arranging for these
targets to install in subdirectories of the appropriate
installation directory, such as `htmldir'. As one example, if
your package has multiple manuals, and you wish to install HTML
documentation with many files (such as the "split" mode output by
`makeinfo --html'), you'll certainly want to use subdirectories,
or two nodes with the same name in different manuals will
overwrite each other.
Please make these `install-FORMAT' targets invoke the commands for
the FORMAT target, for example, by making FORMAT a dependency.
`uninstall'
Delete all the installed files--the copies that the `install' and
`install-*' targets create.
This rule should not modify the directories where compilation is
done, only the directories where files are installed.
The uninstallation commands are divided into three categories,
just like the installation commands. *Note Install Command
Categories::.
`install-strip'
Like `install', but strip the executable files while installing
them. In simple cases, this target can use the `install' target in
a simple way:
install-strip:
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
install
But if the package installs scripts as well as real executables,
the `install-strip' target can't just refer to the `install'
target; it has to strip the executables but not the scripts.
`install-strip' should not strip the executables in the build
directory which are being copied for installation. It should only
strip the copies that are installed.
Normally we do not recommend stripping an executable unless you
are sure the program has no bugs. However, it can be reasonable
to install a stripped executable for actual execution while saving
the unstripped executable elsewhere in case there is a bug.
`clean'
Delete all files in the current directory that are normally
created by building the program. Also delete files in other
directories if they are created by this makefile. However, don't
delete the files that record the configuration. Also preserve
files that could be made by building, but normally aren't because
the distribution comes with them. There is no need to delete
parent directories that were created with `mkdir -p', since they
could have existed anyway.
Delete `.dvi' files here if they are not part of the distribution.
`distclean'
Delete all files in the current directory (or created by this
makefile) that are created by configuring or building the program.
If you have unpacked the source and built the program without
creating any other files, `make distclean' should leave only the
files that were in the distribution. However, there is no need to
delete parent directories that were created with `mkdir -p', since
they could have existed anyway.
`mostlyclean'
Like `clean', but may refrain from deleting a few files that people
normally don't want to recompile. For example, the `mostlyclean'
target for GCC does not delete `libgcc.a', because recompiling it
is rarely necessary and takes a lot of time.
`maintainer-clean'
Delete almost everything that can be reconstructed with this
Makefile. This typically includes everything deleted by
`distclean', plus more: C source files produced by Bison, tags
tables, Info files, and so on.
The reason we say "almost everything" is that running the command
`make maintainer-clean' should not delete `configure' even if
`configure' can be remade using a rule in the Makefile. More
generally, `make maintainer-clean' should not delete anything that
needs to exist in order to run `configure' and then begin to build
the program. Also, there is no need to delete parent directories
that were created with `mkdir -p', since they could have existed
anyway. These are the only exceptions; `maintainer-clean' should
delete everything else that can be rebuilt.
The `maintainer-clean' target is intended to be used by a
maintainer of the package, not by ordinary users. You may need
special tools to reconstruct some of the files that `make
maintainer-clean' deletes. Since these files are normally
included in the distribution, we don't take care to make them easy
to reconstruct. If you find you need to unpack the full
distribution again, don't blame us.
To help make users aware of this, the commands for the special
`maintainer-clean' target should start with these two:
@echo 'This command is intended for maintainers to use; it'
@echo 'deletes files that may need special tools to rebuild.'
`TAGS'
Update a tags table for this program.
`info'
Generate any Info files needed. The best way to write the rules
is as follows:
info: foo.info
foo.info: foo.texi chap1.texi chap2.texi
$(MAKEINFO) $(srcdir)/foo.texi
You must define the variable `MAKEINFO' in the Makefile. It should
run the `makeinfo' program, which is part of the Texinfo
distribution.
Normally a GNU distribution comes with Info files, and that means
the Info files are present in the source directory. Therefore,
the Make rule for an info file should update it in the source
directory. When users build the package, ordinarily Make will not
update the Info files because they will already be up to date.
`dvi'
`html'
`pdf'
`ps'
Generate documentation files in the given format. These targets
should always exist, but any or all can be a no-op if the given
output format cannot be generated. These targets should not be
dependencies of the `all' target; the user must manually invoke
them.
Here's an example rule for generating DVI files from Texinfo:
dvi: foo.dvi
foo.dvi: foo.texi chap1.texi chap2.texi
$(TEXI2DVI) $(srcdir)/foo.texi
You must define the variable `TEXI2DVI' in the Makefile. It should
run the program `texi2dvi', which is part of the Texinfo
distribution.(1) Alternatively, write just the dependencies, and
allow GNU `make' to provide the command.
Here's another example, this one for generating HTML from Texinfo:
html: foo.html
foo.html: foo.texi chap1.texi chap2.texi
$(TEXI2HTML) $(srcdir)/foo.texi
Again, you would define the variable `TEXI2HTML' in the Makefile;
for example, it might run `makeinfo --no-split --html' (`makeinfo'
is part of the Texinfo distribution).
`dist'
Create a distribution tar file for this program. The tar file
should be set up so that the file names in the tar file start with
a subdirectory name which is the name of the package it is a
distribution for. This name can include the version number.
For example, the distribution tar file of GCC version 1.40 unpacks
into a subdirectory named `gcc-1.40'.
The easiest way to do this is to create a subdirectory
appropriately named, use `ln' or `cp' to install the proper files
in it, and then `tar' that subdirectory.
Compress the tar file with `gzip'. For example, the actual
distribution file for GCC version 1.40 is called `gcc-1.40.tar.gz'.
The `dist' target should explicitly depend on all non-source files
that are in the distribution, to make sure they are up to date in
the distribution. *Note Making Releases: Releases.
`check'
Perform self-tests (if any). The user must build the program
before running the tests, but need not install the program; you
should write the self-tests so that they work when the program is
built but not installed.
The following targets are suggested as conventional names, for
programs in which they are useful.
`installcheck'
Perform installation tests (if any). The user must build and
install the program before running the tests. You should not
assume that `$(bindir)' is in the search path.
`installdirs'
It's useful to add a target named `installdirs' to create the
directories where files are installed, and their parent
directories. There is a script called `mkinstalldirs' which is
convenient for this; you can find it in the Texinfo package. You
can use a rule like this:
# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
$(srcdir)/mkinstalldirs $(bindir) $(datadir) \
$(libdir) $(infodir) \
$(mandir)
or, if you wish to support `DESTDIR',
# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
$(srcdir)/mkinstalldirs \
$(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \
$(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \
$(DESTDIR)$(mandir)
This rule should not modify the directories where compilation is
done. It should do nothing but create installation directories.
---------- Footnotes ----------
(1) `texi2dvi' uses TeX to do the real work of formatting. TeX is
not distributed with Texinfo.
File: standards.info, Node: Install Command Categories, Prev: Standard Targets, Up: Makefile Conventions
7.2.7 Install Command Categories
--------------------------------
When writing the `install' target, you must classify all the commands
into three categories: normal ones, "pre-installation" commands and
"post-installation" commands.
Normal commands move files into their proper places, and set their
modes. They may not alter any files except the ones that come entirely
from the package they belong to.
Pre-installation and post-installation commands may alter other
files; in particular, they can edit global configuration files or data
bases.
Pre-installation commands are typically executed before the normal
commands, and post-installation commands are typically run after the
normal commands.
The most common use for a post-installation command is to run
`install-info'. This cannot be done with a normal command, since it
alters a file (the Info directory) which does not come entirely and
solely from the package being installed. It is a post-installation
command because it needs to be done after the normal command which
installs the package's Info files.
Most programs don't need any pre-installation commands, but we have
the feature just in case it is needed.
To classify the commands in the `install' rule into these three
categories, insert "category lines" among them. A category line
specifies the category for the commands that follow.
A category line consists of a tab and a reference to a special Make
variable, plus an optional comment at the end. There are three
variables you can use, one for each category; the variable name
specifies the category. Category lines are no-ops in ordinary execution
because these three Make variables are normally undefined (and you
_should not_ define them in the makefile).
Here are the three possible category lines, each with a comment that
explains what it means:
$(PRE_INSTALL) # Pre-install commands follow.
$(POST_INSTALL) # Post-install commands follow.
$(NORMAL_INSTALL) # Normal commands follow.
If you don't use a category line at the beginning of the `install'
rule, all the commands are classified as normal until the first category
line. If you don't use any category lines, all the commands are
classified as normal.
These are the category lines for `uninstall':
$(PRE_UNINSTALL) # Pre-uninstall commands follow.
$(POST_UNINSTALL) # Post-uninstall commands follow.
$(NORMAL_UNINSTALL) # Normal commands follow.
Typically, a pre-uninstall command would be used for deleting entries
from the Info directory.
If the `install' or `uninstall' target has any dependencies which
act as subroutines of installation, then you should start _each_
dependency's commands with a category line, and start the main target's
commands with a category line also. This way, you can ensure that each
command is placed in the right category regardless of which of the
dependencies actually run.
Pre-installation and post-installation commands should not run any
programs except for these:
[ basename bash cat chgrp chmod chown cmp cp dd diff echo
egrep expand expr false fgrep find getopt grep gunzip gzip
hostname install install-info kill ldconfig ln ls md5sum
mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee
test touch true uname xargs yes
The reason for distinguishing the commands in this way is for the
sake of making binary packages. Typically a binary package contains
all the executables and other files that need to be installed, and has
its own method of installing them--so it does not need to run the normal
installation commands. But installing the binary package does need to
execute the pre-installation and post-installation commands.
Programs to build binary packages work by extracting the
pre-installation and post-installation commands. Here is one way of
extracting the pre-installation commands (the `-s' option to `make' is
needed to silence messages about entering subdirectories):
make -s -n install -o all \
PRE_INSTALL=pre-install \
POST_INSTALL=post-install \
NORMAL_INSTALL=normal-install \
| gawk -f pre-install.awk
where the file `pre-install.awk' could contain this:
$0 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0}
on {print $0}
$0 ~ /^pre-install[ \t]*$/ {on = 1}
File: standards.info, Node: Releases, Prev: Makefile Conventions, Up: Managing Releases
7.3 Making Releases
===================
You should identify each release with a pair of version numbers, a
major version and a minor. We have no objection to using more than two
numbers, but it is very unlikely that you really need them.
Package the distribution of `Foo version 69.96' up in a gzipped tar
file with the name `foo-69.96.tar.gz'. It should unpack into a
subdirectory named `foo-69.96'.
Building and installing the program should never modify any of the
files contained in the distribution. This means that all the files
that form part of the program in any way must be classified into "source
files" and "non-source files". Source files are written by humans and
never changed automatically; non-source files are produced from source
files by programs under the control of the Makefile.
The distribution should contain a file named `README' which gives
the name of the package, and a general description of what it does. It
is also good to explain the purpose of each of the first-level
subdirectories in the package, if there are any. The `README' file
should either state the version number of the package, or refer to where
in the package it can be found.
The `README' file should refer to the file `INSTALL', which should
contain an explanation of the installation procedure.
The `README' file should also refer to the file which contains the
copying conditions. The GNU GPL, if used, should be in a file called
`COPYING'. If the GNU LGPL is used, it should be in a file called
`COPYING.LESSER'.
Naturally, all the source files must be in the distribution. It is
okay to include non-source files in the distribution, provided they are
up-to-date and machine-independent, so that building the distribution
normally will never modify them. We commonly include non-source files
produced by Bison, `lex', TeX, and `makeinfo'; this helps avoid
unnecessary dependencies between our distributions, so that users can
install whichever packages they want to install.
Non-source files that might actually be modified by building and
installing the program should *never* be included in the distribution.
So if you do distribute non-source files, always make sure they are up
to date when you make a new distribution.
Make sure that all the files in the distribution are world-readable,
and that directories are world-readable and world-searchable (octal
mode 755). We used to recommend that all directories in the
distribution also be world-writable (octal mode 777), because ancient
versions of `tar' would otherwise not cope when extracting the archive
as an unprivileged user. That can easily lead to security issues when
creating the archive, however, so now we recommend against that.
Don't include any symbolic links in the distribution itself. If the
tar file contains symbolic links, then people cannot even unpack it on
systems that don't support symbolic links. Also, don't use multiple
names for one file in different directories, because certain file
systems cannot handle this and that prevents unpacking the distribution.
Try to make sure that all the file names will be unique on MS-DOS. A
name on MS-DOS consists of up to 8 characters, optionally followed by a
period and up to three characters. MS-DOS will truncate extra
characters both before and after the period. Thus, `foobarhacker.c'
and `foobarhacker.o' are not ambiguous; they are truncated to
`foobarha.c' and `foobarha.o', which are distinct.
Include in your distribution a copy of the `texinfo.tex' you used to
test print any `*.texinfo' or `*.texi' files.
Likewise, if your program uses small GNU software packages like
regex, getopt, obstack, or termcap, include them in the distribution
file. Leaving them out would make the distribution file a little
smaller at the expense of possible inconvenience to a user who doesn't
know what other files to get.
File: standards.info, Node: References, Next: GNU Free Documentation License, Prev: Managing Releases, Up: Top
8 References to Non-Free Software and Documentation
***************************************************
A GNU program should not recommend, promote, or grant legitimacy to the
use of any non-free program. Proprietary software is a social and
ethical problem, and our aim is to put an end to that problem. We
can't stop some people from writing proprietary programs, or stop other
people from using them, but we can and should refuse to advertise them
to new potential customers, or to give the public the idea that their
existence is ethical.
The GNU definition of free software is found on the GNU web site at
`http://www.gnu.org/philosophy/free-sw.html', and the definition of
free documentation is found at
`http://www.gnu.org/philosophy/free-doc.html'. The terms "free" and
"non-free", used in this document, refer to those definitions.
A list of important licenses and whether they qualify as free is in
`http://www.gnu.org/licenses/license-list.html'. If it is not clear
whether a license qualifies as free, please ask the GNU Project by
writing to <licensing@gnu.org>. We will answer, and if the license is
an important one, we will add it to the list.
When a non-free program or system is well known, you can mention it
in passing--that is harmless, since users who might want to use it
probably already know about it. For instance, it is fine to explain
how to build your package on top of some widely used non-free operating
system, or how to use it together with some widely used non-free
program.
However, you should give only the necessary information to help those
who already use the non-free program to use your program with it--don't
give, or refer to, any further information about the proprietary
program, and don't imply that the proprietary program enhances your
program, or that its existence is in any way a good thing. The goal
should be that people already using the proprietary program will get
the advice they need about how to use your free program with it, while
people who don't already use the proprietary program will not see
anything likely to lead them to take an interest in it.
If a non-free program or system is obscure in your program's domain,
your program should not mention or support it at all, since doing so
would tend to popularize the non-free program more than it popularizes
your program. (You cannot hope to find many additional users for your
program among the users of Foobar, if the existence of Foobar is not
generally known among people who might want to use your program.)
Sometimes a program is free software in itself but depends on a
non-free platform in order to run. For instance, many Java programs
depend on some non-free Java libraries. To recommend or promote such a
program is to promote the other programs it needs. This is why we are
careful about listing Java programs in the Free Software Directory: we
don't want to promote the non-free Java libraries.
We hope this particular problem with Java will be gone by and by, as
we replace the remaining non-free standard Java libraries with free
software, but the general principle will remain the same: don't
recommend, promote or legitimize programs that depend on non-free
software to run.
Some free programs strongly encourage the use of non-free software.
A typical example is `mplayer'. It is free software in itself, and the
free code can handle some kinds of files. However, `mplayer'
recommends use of non-free codecs for other kinds of files, and users
that install `mplayer' are very likely to install those codecs along
with it. To recommend `mplayer' is, in effect, to promote use of the
non-free codecs.
Thus, you should not recommend programs that strongly encourage the
use of non-free software. This is why we do not list `mplayer' in the
Free Software Directory.
A GNU package should not refer the user to any non-free documentation
for free software. Free documentation that can be included in free
operating systems is essential for completing the GNU system, or any
free operating system, so encouraging it is a priority; to recommend
use of documentation that we are not allowed to include undermines the
impetus for the community to produce documentation that we can include.
So GNU packages should never recommend non-free documentation.
By contrast, it is ok to refer to journal articles and textbooks in
the comments of a program for explanation of how it functions, even
though they are non-free. This is because we don't include such things
in the GNU system even they are free--they are outside the scope of
what a software distribution needs to include.
Referring to a web site that describes or recommends a non-free
program is promoting that program, so please do not make links (or
mention by name) web sites that contain such material. This policy is
relevant particularly for the web pages for a GNU package.
Following links from nearly any web site can lead eventually to
non-free software; this is inherent in the nature of the web. So it
makes no sense to criticize a site for having such links. As long as
the site does not itself recommend a non-free program, there is no need
to consider the question of the sites that it links to for other
reasons.
Thus, for example, you should not refer to AT&T's web site if that
recommends AT&T's non-free software packages; you should not refer to a
site that links to AT&T's site presenting it as a place to get some
non-free program, because that link recommends and legitimizes the
non-free program. However, that a site contains a link to AT&T's web
site for some other purpose (such as long-distance telephone service)
is not an objection against it.
File: standards.info, Node: GNU Free Documentation License, Next: Index, Prev: References, Up: Top
Appendix A GNU Free Documentation License
*****************************************
Version 1.3, 3 November 2008
Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
`http://fsf.org/'
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or
noncommercially. Secondarily, this License preserves for the
author and publisher a way to get credit for their work, while not
being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.
It complements the GNU General Public License, which is a copyleft
license designed for free software.
We have designed this License in order to use it for manuals for
free software, because free software needs free documentation: a
free program should come with manuals providing the same freedoms
that the software does. But this License is not limited to
software manuals; it can be used for any textual work, regardless
of subject matter or whether it is published as a printed book.
We recommend this License principally for works whose purpose is
instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium,
that contains a notice placed by the copyright holder saying it
can be distributed under the terms of this License. Such a notice
grants a world-wide, royalty-free license, unlimited in duration,
to use that work under the conditions stated herein. The
"Document", below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as "you". You
accept the license if you copy, modify or distribute the work in a
way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section
of the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall
subject (or to related matters) and contains nothing that could
fall directly within that overall subject. (Thus, if the Document
is in part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter of
historical connection with the subject or with related matters, or
of legal, commercial, philosophical, ethical or political position
regarding them.
The "Invariant Sections" are certain Secondary Sections whose
titles are designated, as being those of Invariant Sections, in
the notice that says that the Document is released under this
License. If a section does not fit the above definition of
Secondary then it is not allowed to be designated as Invariant.
The Document may contain zero Invariant Sections. If the Document
does not identify any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
that says that the Document is released under this License. A
Front-Cover Text may be at most 5 words, and a Back-Cover Text may
be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images
composed of pixels) generic paint programs or (for drawings) some
widely available drawing editor, and that is suitable for input to
text formatters or for automatic translation to a variety of
formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup, or absence of
markup, has been arranged to thwart or discourage subsequent
modification by readers is not Transparent. An image format is
not Transparent if used for any substantial amount of text. A
copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format,
SGML or XML using a publicly available DTD, and
standard-conforming simple HTML, PostScript or PDF designed for
human modification. Examples of transparent image formats include
PNG, XCF and JPG. Opaque formats include proprietary formats that
can be read and edited only by proprietary word processors, SGML or
XML for which the DTD and/or processing tools are not generally
available, and the machine-generated HTML, PostScript or PDF
produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the
material this License requires to appear in the title page. For
works in formats which do not have any title page as such, "Title
Page" means the text near the most prominent appearance of the
work's title, preceding the beginning of the body of the text.
The "publisher" means any person or entity that distributes copies
of the Document to the public.
A section "Entitled XYZ" means a named subunit of the Document
whose title either is precisely XYZ or contains XYZ in parentheses
following text that translates XYZ in another language. (Here XYZ
stands for a specific section name mentioned below, such as
"Acknowledgements", "Dedications", "Endorsements", or "History".)
To "Preserve the Title" of such a section when you modify the
Document means that it remains a section "Entitled XYZ" according
to this definition.
The Document may include Warranty Disclaimers next to the notice
which states that this License applies to the Document. These
Warranty Disclaimers are considered to be included by reference in
this License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and
has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that you
add no other conditions whatsoever to those of this License. You
may not use technical measures to obstruct or control the reading
or further copying of the copies you make or distribute. However,
you may accept compensation in exchange for copies. If you
distribute a large enough number of copies you must also follow
the conditions in section 3.
You may also lend copies, under the same conditions stated above,
and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly
have printed covers) of the Document, numbering more than 100, and
the Document's license notice requires Cover Texts, you must
enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and
Back-Cover Texts on the back cover. Both covers must also clearly
and legibly identify you as the publisher of these copies. The
front cover must present the full title with all words of the
title equally prominent and visible. You may add other material
on the covers in addition. Copying with changes limited to the
covers, as long as they preserve the title of the Document and
satisfy these conditions, can be treated as verbatim copying in
other respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto
adjacent pages.
If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a