home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 22 gnu / 22-gnu.zip / bakev100.zip / whybake.doc < prev   
Text File  |  1995-05-22  |  4KB  |  65 lines

  1. 1) Why use a project manager?
  2. 2) Why THIS project manager?
  3.  
  4. --- Why you'd want to use a project manager like bake:
  5.  
  6. If you just type "gcc *.cc" every time you want to compile your program,
  7. it will re-compile every single source file in the directory, even if
  8. you only changed one of them.  This is really, really slow.  Using some
  9. sort of project co-ordinator, like Bake, allows you to just re-compile
  10. the files that have changed, saving a lot of time, especially with large
  11. multi-file programs.
  12.  
  13. In addition to that, wildcards aren't specific.  You may have more than
  14. one program in a given directory.  There could be two or three different
  15. overlapping sets of files which create different executables.  This means
  16. you have to list just the files you want on the command line, every time
  17. you want to compile a given executable.  If there are twenty source code
  18. files, this is a pain.
  19.  
  20. Also, you usually want to give the compiler some command line options to
  21. at least tell it what you're making (such as a .dll or a 32 bit OS/2 exe),
  22. and it's a pain to type the options in each time.  Plus you have to call
  23. the resource compiler manually to make a binary .res file from the .rc
  24. file, and you have to remember to include the .def file(s) too.
  25.  
  26. If you're tracking down a bug in one function, in just one of the twenty
  27. source code files that make up a large program, and have to compile the
  28. whole thing a dozen times in the process, plus you want to compile a
  29. 32 bit OS/2 native executable that includes a .dll file and two extra
  30. static libraries...  Well, a project manager could come in handy.
  31.  
  32. --- Why Bake is better than Make:
  33.  
  34. The old, established project manager is "make", which uses "make files".
  35. The name bake came from "better make", because it was an attempt to
  36. improve on make by starting over from scratch.
  37.  
  38. Bake files are easier to learn.  There are only two types of lines in a
  39. bake file: target and source lines.  Make is an entire programming language
  40. that has had several books written on it.
  41.  
  42. Bake files are easier to create.  You can create a complete Bake file from
  43. scratch in under fifteen seconds with a standard text editor.  Just try
  44. that with make files, where the difference between spaces and the "tab"
  45. character is important.
  46.  
  47. Bake files are easier to maintain.  With Bake files, the Bake executable
  48. will figure out the dependencies on its' own.  It'll look through the source
  49. files you list, figure out which header files you #included, and recursively
  50. look through them too to see if any have changed since the last compile.  It
  51. does all the work for you, you just have to tell it which files are in this
  52. program and what the .exe should be called.  With make files, you have to
  53. explicitly state the dependencies for every single source file, which is a
  54. lot of work and requires a lot of manual updating as your program evolves.
  55.  
  56. Bake is specific to the EMX port of GCC, meaning it already knows a lot
  57. of information about the compiler.  It knows how to compile a 32 bit OS/2
  58. executable, an emulated unix executable, a hybrid OS/2 and unix emulation
  59. executable, a dynamic link library, and two types of statically linked
  60. libraries.  Make has no idea what it's doing until you tell it.  It can be
  61. programmed to compile basic, fortran, cobol, pascal, lisp, smalltalk, tex,
  62. or whatever, but you have to give it a dozen lines describing the language
  63. you're using and your compiler before you can even start telling it about
  64. your actual source code.
  65.