binstall_hp.1 2.7 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788
  1. .\" $XConsortium: binstall_hp.1 /main/3 1995/10/30 14:05:43 rswiston $
  2. .TH binstall_hp 1 "" "" HP-UX
  3. .ds )H Hewlett-Packard
  4. .ds ]W January 1994
  5. .SH NAME
  6. binstall_hp \- build environment installation path availability
  7. .SH DESCRIPTION
  8. This man page describes the usage of the build install mechanism at
  9. Hewlett-Packard. The focus is primarily on the default locations for the
  10. install paths.
  11. .TP 0
  12. All build installation paths are available through the
  13. .I /binstall
  14. directory on all build systems. If you need to set up
  15. .I /binstall
  16. on a non-build system, examine the symbolic links and nfs mounts in
  17. .IR /binstall .
  18. .SH
  19. In
  20. .I /binstall
  21. each build tree that has an installed build is listed as a subdirectory.
  22. Each subdirectory under the build tree subdirectory contains an instance
  23. of a build environment for that build tree. There are 2 types of build
  24. tree subdirectories: automatically generated directories based on
  25. .I mm_dd
  26. (month_date from the
  27. .I date
  28. command) and any specially named subdirectories. There is also a
  29. symbolic link
  30. .I latest
  31. which points to the most recent
  32. .I mm_dd
  33. directory. Using the
  34. .I latest
  35. directory will normally be equivalent to pointing
  36. .I TOP
  37. to a build tree. However, if the build tree is unstable,
  38. .I latest
  39. may be reset to the last stable build.
  40. .SH
  41. Each
  42. .I mm_dd
  43. directory has a definite lifespan that depends on the
  44. importance of the tree and the availability of disk space. This
  45. information is stored in
  46. .IR /binstall/pathlife .
  47. .SH EXAMPLES
  48. Developer's will usually either reset
  49. .I TOP
  50. to
  51. .I /binstall/treename/latest
  52. or will set
  53. .I TOP
  54. to an explicit date ->
  55. .I /binstall/treename/mm_dd.
  56. The advantage of the former is that it allows you to stay in closer
  57. touch to the daily bits. The advantage of the latter is that, for a
  58. popular tree, you can choose a date when a stable build occurs and use that
  59. date's build until it expires. However, it would be good practice to do
  60. a test build against the latest bits before checking a critical file
  61. in.
  62. .TP 3
  63. .nf
  64. Example 1: Point your clone to the latest directory for /x/cde_hp700_90.
  65. cd to your clone
  66. make TOP=/x/cde_hp700_90/latest Makefile
  67. make Makefiles (optional)
  68. .fi
  69. .TP
  70. .nf
  71. Example 2: Point your clone to the Jan. 3rd build for /x/cde_hp700_90.
  72. cd to your clone
  73. make TOP=/x/cde_hp700_90/01_03 Makefile
  74. make Makefiles (optional)
  75. .SH PACKAGE INFORMATION
  76. Check the
  77. .I /binstall
  78. directory on any build system to scan the available paths.
  79. The duration of mm_dd paths is normally 7 days. For debuggable trees, the
  80. default duration will be 2-4 days. The duration for each set of paths
  81. can be read from the file
  82. .IR /binstall/pathlife.
  83. The binstall mechanism
  84. was developed by Marc Ayotte,
  85. WTD-CV, Hewlett-Packard.
  86. .SH SEE ALSO
  87. binstall(1),
  88. binstall(5).