> Will it work to apply patch in ~/checkout/gnome2/MODULE/ and then > build it with something like: > $ jhbuild buildone --no-network MODULE
Yes that works fine. I usually even omit --no-network so I remain in sync with trunk You can also run $ jhbuild shell that will open a shell that has all all the relevant environment variables pointing to the right locations. In that shell you can just run make > For testing purposes? Cause this seems to me to be the equivalent of > adding patches variable in conary recipes. > > With best regards > > > > Dmitrijs Ledkovs > > > > On Wed, Aug 6, 2008 at 22:55, Jaap A. Haitsma <[EMAIL PROTECTED]> wrote: >> On Wed, Aug 6, 2008 at 8:12 PM, Dmitrijs Ledkovs >> <[EMAIL PROTECTED]> wrote: >>> Hello Gnome Love =D >>> >>> == Intro == >>> >>> I'm learning to program with GTK+ using Foundation of Gtk+ development >>> book and already starting to learn Gnome codebase while finding >>> suitable gnome-love bugs for me to fix. >>> >>> Currently I started to use JHbuild and I have some questions on a >>> workflow I should use for building, hacking, testing, creating patch, >>> testing patch and submitting it. >>> >>> == Current Workflow == >>> >>> I used to clone from git-mirror. Then I would get dependencies like this: >>> $ sudo apt-get install build-dep # i'm using Ubuntu 8.04 >>> >>> Then I would build the fancy new app (e.g. Epiphany or Empathy I like >>> them a _lot_) into /usr/local and happily use it. Once a week or so >>> pulling updates recompiling and continuing to use it =D. >>> >>> == Future Workflow == >>> >>> Now I want to start fixing bugs =D and I'm a bit confused. Naturally I >>> would create a branch in git, do 5-10 commits to finally fix a bug. >>> Recompile, test, test, test, then pull updates on master branch and >>> create a diff / patch between the two. And submit it to the >>> bugzilla/mailing lists/maintainers. >>> >>> == But JHBuild == >>> >>> Hmmmm........ I'm suppose to hack on the code it checked-out after >>> $ jhbuild build epiphany >>> and test my changes using it, and then do diff between mywork and the >>> previous state of jhbuild? Cause I don't understand how significant it >>> is to use everything from jhbuild instead of my distribution repo's? >>> Cause my bugfixing is long from depending on bleeding edge build >>> enviromnet. >>> >>> == Conclusion == >>> >>> Please explain whether JHbuild is used just to test compete new gnome >>> or whether it should also be used during bug fixing? >>> >>> Please confirm if it is ok to use combined current+future workflow for >>> working on a particular gnome app and submitting patches to the >>> bugzilla. >>> >>> Or please prepose alternative workflow with preferably git/bzr. Cause >>> git is the first scm I used/learned and bzr is easy =D. >>> >> >> Your current workflow using a git mirror is fine (I'm assuming your >> git-mirror is a mirror of GNOME svn and not some repo which contains >> distro specific changes) >> >> jhbuild is just handy if you want to build the complete GNOME desktop >> from source because it makes sure that the right libraries also get >> build >> >> Jaap >> > _______________________________________________ > gnome-love mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-love > _______________________________________________ gnome-love mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-love
