Bric::Hacker - A guide for Bricolage hackers.
$Revision: 1.3.2.1 $
$Date: 2002/03/12 18:50:33 $
This document is designed to provide information useful to Bricolage developers. If you've got questions about hacking Bricolage that aren't answered here please post to the Bricolage developer's mailing-list (see below) and tell us about it.
Bricolage has a number of mailing-lists that are relevant to developers:
This is the mailing-list for normal Bricolage users. This is a good place to go with questions about how the application works and should work. To subscribe go to:
http://lists.sourceforge.net/lists/listinfo/bricolage-general
This is the place to discuss Bricolage development, propose changes, post patches and penetrate markets. To subscribe go to:
http://lists.sourceforge.net/lists/listinfo/bricolage-devel
This list gets an email for every commit to the CVS tree (see below for more about CVS). DO NOT POST TO THIS LIST! To subscribe:
http://lists.sourceforge.net/lists/listinfo/bricolage-commits
This list gets an email for every bug-report submitted to Bugzilla (see below for Bugzilla details). DO NOT POST TO THIS LIST! To subscribe:
http://lists.sourceforge.net/lists/listinfo/bricolage-bugs
If you're developing Bricolage then you should be working with the latest code from CVS. You can browse the CVS tree at:
http://sourceforge.net/cvs/?group_id=34789You'll also find information there on connecting to the repository to checkout a working copy.
Bricolage has a Bugzilla server dedicated to it:
http://bricolage-bugzilla.about.comYou should use this system to report bugs in Bricolage. If you're looking for something to do you can also use the system to find open bug and fix them. For more things to do see Bric::ToDo.
Patches should be generated using the "cvs diff -u" command on each of the files modified. Always create patches using the most recent CVS version if possible. Send your patches to the bricolage-devel list mentioned above.
Try to follow the style of the existing Bricolage code. [ David, want to elaborate on POD, Mason, etc? ]
Bricolage is a complex application and debugging can be difficult. Here are some tips to help you find bugs faster:
Turn on QA_MODE in your bricolage.conf. This will cause the UI to display a bunch of useful data the bottom of every page including session state, cache state, cookies and CGI args. Also, QA_MODE turns on PerlWarn (use warnings) and causes error messages to include more information.
Set DBI_DEBUG and DBI_CALL_TRACE to 1 in your bricolage.conf. DBI_DEBUG records every database call in the logs complete with SQL and arguments. DBI_CALL_TRACE adds a a subroutine call trace for each statement showing where the database call originated. This generates a lot of data but it can be very helpful.
Look at the database directly using psql. Many bugs in Bricolage can only be successful diagnosed by examining records being created in the database.
Sam Tregar <stregar@about-inc.com>