= Welcome to Project-Builder Wiki = = Design Ideas around the project-builder.org project = Since 2005 that I took over the maintenance of the [http://www.mondorescue.org MondoRescue] project, I have passed time developing code on the periphery of the project to allow me to easily build packages from Subversion, deliver them, manage them, ... I met a lot of Open Source project which are suffering from the same barrier for their adoption as mondo suffered in the past: without native packaging for your distribution you have much less people testing your software, trying it, less chance to be integrated in distributions, ... Then I wanted to also work on another project called [http://trac.dploy.org dploy.org] which uses the great [http://www.LinuxCOE.org LinuxCOE]. However that LinuxCOE project had exactly the same issue as previously mentioned, no packaging, on install from CVS, so smaller community. And in order for me to put something on a prouction server, I want it packaged :-) So I decided it could be a good idea to reuse the scripts made for mondo to package LinuxCOE. However, they were too specific, even if the ideas could be reused (that was my 3rd generation of build scripts, so ideas were more advanced than the code). = Technical ideas around the project-builder.org (aka pb) project = * use perl. It makes coding so more efficient, powerful and also fun * use AppConfig. A lot of information is managed under a configuration file format and AppConfig makes it trivial to handle them. BTW look at that [http://trac.project-builder.org/browser/devel/pb-doc/AppConfig%3A%3AFile.patch patch] as the versions of AppConfig from 1.63 and up to 1.66 at least have a bug for handling hashes correctly this fixes. Cf: http://rt.cpan.org/Ticket/Display.html?id=28766 = Example of use on LinuxCOE = When the project was mature enough to package correctly mondorescue and itself, I then decided it was time to try it on another unrelated project to see how difficult it could be and document that experience so that others could also begin to use pb for their own project. You first have to create a .pbrc configuration file in your home directory, which will setup things globally. Here are my .pbrc LinuxCOE relative entries: {{{ $ grep -E '^#|linuxcoe|default' ~/.pbrc # # Root of the temp file used to store info on the project # Is also used to determine the root directory of the project # No default option allowed here as they need to be all different # pbrc linuxcoe = /users/bruno/LinuxCOE/cvs/pbrc # # Which CMS system is used # cms linuxcoe = cvs cms default = svn # # Packager label # packager linuxcoe = "Bruno Cornec " # # For CVS managed projects # (Optional) # cvsroot linuxcoe = ":pserver:anonymous@linuxcoe.cvs.sourceforge.net:/cvsroot/linuxcoe" }}} Should be obvious for the content. Note that the format is in general {{{ pb-keyword project = value }}} which means that here I named my project for pb linuxcoe (I can choose what I want be need to be consistent everywhere). Then you have to go under the directory you planned to store the project you want to package (/users/bruno/LinuxCOE/cvs) and you have to create there a directory pbconf which will contain everything related to project-builder around your own project. The pbrc file you indicated in the configuation file will be managed automatically by pb and you don't have to care of it. Just to reference where it will be, which will in turn give to project-builder the information of the project's directory. {{{ $ cd /users/bruno/LinuxCOE/cvs $ mkdir pbconf }}} The main configuration file under pbconf should be named with the name of the project (the one used above in the .pbrc file) with the pb extension. the one created for LinuxCOE looks like that: {{{ $ cat linuxcoe.pb # # Project Builder configuration file # For project LinuxCOE # # $Id$ # # # Global version/tag for the project # projver pb = devel projtag pb = 1 # Adapt to your needs: # Optional if you need to overwrite the global values above # pkgver nil pkgtag nil # Hash of default package/package directory # defpkgdir system-designer = SystemDesigner defpkgdir system-designer-docs = docs # Hash of additional package/package directory # extpkgdir system-designer-fedora = SystemDesigner-Fedora # Hash of valid version names # version devel version stable # List of additional files on which to apply filters # Files are mentioned relatively to pbroot # filteredfiles system-designer = filteredfiles system-designer-docs = }}} I inform pb that I will produce packages with a verion-tag of devel-1, that no local package should have a different version than the project version (pkgver/pkgtag), that my default package will be system-designer (pb will work on it by default all the time) and that additional packages it may deal with are system-designer-docs and system-designer-fedora. In addition to standard version with numbers, pb will accpet the version devel and stable. And finally, I give to the name of all files (per package) that it will have to filter to produce the packages - more on that later on. == Concerning trac == * TracGuide -- Built-in Documentation * [http://projects.edgewall.com/trac/ The Trac project] -- Trac Open Source Project * [http://projects.edgewall.com/trac/wiki/TracFaq Trac FAQ] -- Frequently Asked Questions * TracSupport -- Trac Support For a complete list of local wiki pages, see TitleIndex. Trac is brought to you by [http://www.edgewall.com/ Edgewall Software], providing professional Linux and software development services to clients worldwide. Visit http://www.edgewall.com/ for more information.