/* * 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. */