Author: jgg
Date: 1998-11-21 06:05:52 GMT
Fixed docs
-NOTE: The ChangeLog generator will parse for names and email addresses. The
-'CVS:<name>' tag should indicate who this pair refers to.
-
The project hierachy stands at:
The project hierachy stands at:
-CVS:bcwhite Brian White <bcwhite@verisim.com>
-- Project Leader
-- General organization, dispute resolution, final say on "capabilities"
-
-CVS:jgg Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>
-- Chief Programmer
-- Code organization, task breakdown, final say on "code"
-
-CVS:tom Tom Lees <tom@lpsg.demon.co.uk>
-- Dpkg Consultant
-- Make system
-- Expert on compatibility with existing dpkg, dependency algorithms, etc.
+CVS:jgg Jason Gunthorpe <jgg@debian.org>
+- Project leader
CVS:srivasta Manoj Srivastava <srivasta@datasync.com>
- Dependency Expert
CVS:srivasta Manoj Srivastava <srivasta@datasync.com>
- Dependency Expert
-CVS:behanw Behan Webster <behanw@verisim.com>
-- Chief Designer
-- Screen layout, ease of use, final say on "user interface"
-
CVS:che Ben Gertzfield <che@debian.org>
CVS:che Ben Gertzfield <che@debian.org>
+- Packaging and Releases
CVS:branden Branden Robinson <branden@purdue.edu>
- Man Page Documentation
CVS:branden Branden Robinson <branden@purdue.edu>
- Man Page Documentation
-CVS:scott Scott Ellis <storm@gate.net>
-- .deb archive creater
-
CVS:doogie Adam Heath <doogie@debian.org>
CVS:doogie Adam Heath <doogie@debian.org>
-- FTP method author
\ No newline at end of file
+- FTP method author
+
+Past Contributures:
+
+Brian White <bcwhite@verisim.com> - Project originator
+Tom Lees <tom@lpsg.demon.co.uk> - DPKG documentation and ideas
+Behan Webster <behanw@verisim.com> - Original GUI design
+Scott Ellis <storm@gate.net> - Original packaging and beta releases
+Many other bug reports through the Debian Bug system
+
+NOTE: The ChangeLog generator will parse for names and email addresses. The
+'CVS:<name>' tag should indicate who this pair refers to.
+
source directory irregardless of the destination directory. This means
#include "" and #include <> work as epected and more importantly
running 'make' in the source directory will work as expected. The
source directory irregardless of the destination directory. This means
#include "" and #include <> work as epected and more importantly
running 'make' in the source directory will work as expected. The
-environment variable or make parameter 'BUILD' sets the build directory.
+environment variable or make parameter 'BUILD' set the build directory.
It may be an absolute path or a path relative to the top level directory.
By default build/ will be used with a fall back to ./ This means
you can get all the advantages of a build directory without having to
It may be an absolute path or a path relative to the top level directory.
By default build/ will be used with a fall back to ./ This means
you can get all the advantages of a build directory without having to
automake (I really don't know why) and autoconf and requires doing
aclocal -I buidlib
autoconf
automake (I really don't know why) and autoconf and requires doing
aclocal -I buidlib
autoconf
+[Altertatively you can run make startup in the top level build dir]
Autoconf is configured to do some basic system probes for optional and
required functionality and generate an environment.mak and include/config.h
Autoconf is configured to do some basic system probes for optional and
required functionality and generate an environment.mak and include/config.h
ones in the top level tree. Make is not able to resolve rules that
go to the same file through different paths and this will confuse the
depends mechanism. I recommend always using the makefiles in the
ones in the top level tree. Make is not able to resolve rules that
go to the same file through different paths and this will confuse the
depends mechanism. I recommend always using the makefiles in the
-source directory and exporting BUILD
+source directory and exporting BUILD.