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
|
/*
* Guidelines for using this file vs. configure.ac
*
* (1) If it already exists in configure.ac, leave it there.
*
* (2) If it needs to take effect at configure (not compile) time, it *needs*
* to go in configure.ac.
*
* (3) If it affects file paths, which are the things most likely to be based
* on an OS or distribution's generic filesystem hierarchy and not on a
* particular package's definition (e.g. an RPM specfile), it should probably
* go in configure.ac.
*
* (4) If it affects default sizes, limits, thresholds, or modes of operation
* (e.g. IPv4 vs. IPv6), it should probably go here.
*
* (5) For anything else, is it more like the things in 3 or the things in 4?
* Which approach is more convenient for the people who are likely to use the
* new option(s)? Make your best guesses, confirm with others, and go with
* what works.
*/
#define SITE_H_ENABLE_LEAST_PRIORITY "on"
#define SITE_H_MD_CACHE_TIMEOUT "1"
#define SITE_H_NFS_DISABLE "on"
/*
* As an example of how to use this file, here's what the Facebook version looks
* like:
#define SITE_H_ENABLE_LEAST_PRIORITY "off"
#define SITE_H_MD_CACHE_TIMEOUT "180"
#define SITE_H_NFS_DISABLE "off"
* Each time we add a value here, we lessen the risk of values being
* inconsistent across production automation, test automation, and manual
* developer testing. We also save effort compared to updating values for each
* kind of external automation. To do the same thing with configure scripts or
* specfiles, we'd have to make much more complicated and less discoverable
* changes there.
*
* Other orgs are likely to have the same issues regarding their preferred
* settings, and likewise should add their favorites here as well.
*/
|
