home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 22 gnu
/
22-gnu.zip
/
bakev100.zip
/
whybake.doc
< prev
Wrap
Text File
|
1995-05-22
|
4KB
|
65 lines
1) Why use a project manager?
2) Why THIS project manager?
--- Why you'd want to use a project manager like bake:
If you just type "gcc *.cc" every time you want to compile your program,
it will re-compile every single source file in the directory, even if
you only changed one of them. This is really, really slow. Using some
sort of project co-ordinator, like Bake, allows you to just re-compile
the files that have changed, saving a lot of time, especially with large
multi-file programs.
In addition to that, wildcards aren't specific. You may have more than
one program in a given directory. There could be two or three different
overlapping sets of files which create different executables. This means
you have to list just the files you want on the command line, every time
you want to compile a given executable. If there are twenty source code
files, this is a pain.
Also, you usually want to give the compiler some command line options to
at least tell it what you're making (such as a .dll or a 32 bit OS/2 exe),
and it's a pain to type the options in each time. Plus you have to call
the resource compiler manually to make a binary .res file from the .rc
file, and you have to remember to include the .def file(s) too.
If you're tracking down a bug in one function, in just one of the twenty
source code files that make up a large program, and have to compile the
whole thing a dozen times in the process, plus you want to compile a
32 bit OS/2 native executable that includes a .dll file and two extra
static libraries... Well, a project manager could come in handy.
--- Why Bake is better than Make:
The old, established project manager is "make", which uses "make files".
The name bake came from "better make", because it was an attempt to
improve on make by starting over from scratch.
Bake files are easier to learn. There are only two types of lines in a
bake file: target and source lines. Make is an entire programming language
that has had several books written on it.
Bake files are easier to create. You can create a complete Bake file from
scratch in under fifteen seconds with a standard text editor. Just try
that with make files, where the difference between spaces and the "tab"
character is important.
Bake files are easier to maintain. With Bake files, the Bake executable
will figure out the dependencies on its' own. It'll look through the source
files you list, figure out which header files you #included, and recursively
look through them too to see if any have changed since the last compile. It
does all the work for you, you just have to tell it which files are in this
program and what the .exe should be called. With make files, you have to
explicitly state the dependencies for every single source file, which is a
lot of work and requires a lot of manual updating as your program evolves.
Bake is specific to the EMX port of GCC, meaning it already knows a lot
of information about the compiler. It knows how to compile a 32 bit OS/2
executable, an emulated unix executable, a hybrid OS/2 and unix emulation
executable, a dynamic link library, and two types of statically linked
libraries. Make has no idea what it's doing until you tell it. It can be
programmed to compile basic, fortran, cobol, pascal, lisp, smalltalk, tex,
or whatever, but you have to give it a dozen lines describing the language
you're using and your compiler before you can even start telling it about
your actual source code.