README-FIRST 3.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081
  1. Woof2 README
  2. ------------
  3. *PLEASE READ ALL OF THIS, INCLUDING THE EXTRA NOTES*
  4. Woof2 has two major enhancements over "Woof1":
  5. 1. Supports multiple architectures (exs: x86, arm)
  6. 2. VCS (Version Control System) friendly
  7. This is achieved by splitting the 'woof-tree' of Woof1 into three directories
  8. 'woof-arch', 'woof-code' and 'woof-distro':
  9. woof-arch: architecture-dependent (x86, arm) files, mostly binary executables.
  10. woof-code: the core of Woof. Mostly scripts.
  11. woof-distro: distro-configuration (Debian, Slackware, etc.) files.
  12. To create a working directory, named 'woof-out_*', that you will then use just
  13. like you did before with Woof1, you first have to run the 'merge2out'
  14. script. This merges the three directories into a directory named 'woof-out-*'.
  15. You then 'cd' into woof-out_* and run the usual Puppy build scripts.
  16. The great thing about this merge operation is that you can choose exactly what
  17. you want to go into woof-out. You can choose the host system that you are building
  18. on (usually x86), the target (exs: x86, arm), the compatible-distro (ex: debian),
  19. and the compat-distro version (ex: squeeze).
  20. So, you create woof-out without any confusing inappropriate content.
  21. The script 'merge2out' has further explanation of the VCS support,
  22. but basically, 'woof-code' content has been modified to make it VCS-friendly.
  23. A VCS such as Fossil will be able to handle the dirs 'woof-arch', 'woof-code'
  24. and 'woof-distro'.
  25. The 'merge2out' removes those VCS-friendly features from woof-out, so that
  26. woof-out is restored to a normal Woof build environment.
  27. For example, woof-code has a file named 'EMPTYDIRMARKER' inside every empty
  28. directory, and these are removed from woof-out.
  29. Another example, woof-code/boot/initrd-tree0 and woof-code/rootfs-skeleton has
  30. 'dev' directory converted to *DEVDIR.tar.gz tarballs (and stored in woof-arch),
  31. as VCS's cannot handle device nodes.
  32. So, to get going with Woof2, open a terminal inside 'woof2' and do this:
  33. # ./merge2out
  34. # cd ../woof-out_<REST OF DIRNAME>
  35. Regards,
  36. Barry Kauler
  37. Nov. 24, 2011
  38. bkhome.org/blog
  39. NOTE Nov. 25, 2011
  40. ------------------
  41. Directory woof-code has a lot of binary files in it, but git, svn, mercurial and
  42. fossil all support binary files -- in fact they feature automatic detection of
  43. binary files. Note, cvs has very limited support for binary files.
  44. I was going to move all binary files from woof-code to woof-arch, thinking to have
  45. all binary files in woof-arch only, and started some code in script 'vcs-workarounds'
  46. (commented out). The thinking was that woof-arch could be left out of the VCS if it
  47. does not support binary files, but as most do, I decided that it is an unnecessary
  48. complication.
  49. I did a bit of research and found that a lot of projects store binary files in
  50. their VCS, so Woof is not so unusual.
  51. So, woof-code is allowed to have architecture-independent binary files, such as
  52. images. woof-arch has architecture-dependent binary files, such as executables
  53. for x86 or arm.
  54. NOTE Nov. 26, 2011
  55. ------------------
  56. Woof1 was for building an x86-based Puppy only. Woof2 inherits all of that, so
  57. can be used for x86 "build" and x86 "target" environments. When you run the
  58. 'merge2out' script, do not choose anything else.
  59. I am currently working on x86-build, arm1176jzf-s-target, but it is not yet
  60. complete. Basically, more arm packages are needed to build a working Puppy.
  61. I am working on an arm Dpup, using Debian Squeeze compatible-distro binary
  62. packages.