3f66f6a5b3
This keyword is not expanded by Git which means it's not replaced with the correct revision value in the releases made using git-based scripts and it's confusing to have lines with unexpanded "$Id$" in the released files. As expanding them with Git is not that simple (it could be done with git archive and export-subst attribute) and there are not many benefits in having them in the first place, just remove all these lines. If nothing else, this will make an eventual transition to Git simpler. Closes #14487. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775 |
||
---|---|---|
.. | ||
build_all | ||
changelog | ||
compat | ||
control.in | ||
copyright | ||
libwxbase-dbg.postinst | ||
libwxbase-dbg.prerm | ||
libwxbase-dev.postinst | ||
libwxbase-dev.prerm | ||
libwxgtk-dbg.postinst | ||
libwxgtk-dbg.prerm | ||
libwxgtk-dev.postinst | ||
libwxgtk-dev.prerm | ||
libwxmsw-dbg.postinst | ||
libwxmsw-dbg.prerm | ||
libwxmsw-dev.postinst | ||
libwxmsw-dev.prerm | ||
lintian-override.in | ||
pycrust.desktop | ||
pyshell.desktop | ||
python-wxgtk-dbg.postinst | ||
python-wxgtk-dbg.prerm | ||
python-wxgtk.docs | ||
python-wxgtk.postinst | ||
python-wxgtk.prerm | ||
python-wxtools.menu | ||
README.Debian | ||
README.examples | ||
README.HowToBuild.txt | ||
rules | ||
unpack_examples.sh.in | ||
wx-config.1 | ||
wx-doc.doc-base | ||
wx-doc.docs | ||
wx-examples.examples | ||
wxPython-tools.1 | ||
wxrc-tools.1 | ||
xrced.desktop |
How to build the Debian wx packages =================================== This file is currently just a brain dump of my experiences with building the Debian wx packages, based on various experimentations, and Googling around. Please don't take anything said here as authoritative or written in stone. Although I've been able to get things to work fairly reliably, I still feel pretty clueless about some things. Overview -------- Contrary to how RPM and other packaging systems work, building Debian packages is done with an expanded source tree instead of using a tarball. Inside the toplevel of the source tree you'll find a subdir named debian, and within this dir are various files used by the build. The most important of these are the control file and the rules file. The control file specifies the metadata about each package, such as name, description, dependencies, etc. Interestingly, the version number of the current build is not in the control file as might be expected, but is instead taken from the changelog file. I guess this is a way for debian to make sure that there is always an updated changelog for every release, but it is very non-intuitive to say the least. The rules file is a Makefile, and is executable with a #! that runs make on itself. This lets you execute commands from the toplevel source dir like: ./debian/rules build While theoretically you could build the wx packages directly from your CVS workspace this won't work (currently) for a couple reasons. First, the debian/rules file is currently looking at the name of the toplevel source dir and extracting from it the flavour name (if present) for use in passing to --with-flavor configure flag. (I'm considering changing how it finds this value for 2.7 so, for example, the debian packages could also be built from the wxPython source tarball...) Second, since the build tools use the current source dir for creating the source package, you'll probably want to start with a clean source tree that has had unnecessary things removed from it. There is a Makefile target that will create a minimized and clean source tree for you, and will name it as debian/rules expects. To use it go to a build dir where you've already run configure, and then run: make debian-dist This will result in a new source tree with a name like wxwidgets2.7-2.7.0.0 that is located as a sibling to the toplevel of the current source tree. Environment ----------- The various dpkg helper tools will use some environment settings to provide default values. I have these set: DEBFULLNAME='Robin Dunn' DEBEMAIL=robin@alldunn.com DEBSIGN_KEYID='Robin Dunn <robin@alldunn.com>' DEBUILD_DPKG_BUILDPACKAGE_OPTS='-i -ICVS -I.svn' Notice the DEBSIGN_KEYID value. If this is set (and you have a matching gnupg key) then the packages will be digitally signed when they are built. If you are building packages that you intend to be installable on machines other than your own, then I recommend that you either have a separate machine with a minimal OS install, or set up a chroot environment and do the builds there. The reason for this is to minimize unexpected extra dependencies that the built packages will have because of extra things you have installed on your desktop system, for example OpenGL libs installed by your video card drivers. Using a chroot will also allow you to build packages for different versions of Debian (or Ubuntu) if desired. There is a good description of setting up a chroot environment here: https://wiki.ubuntu.com/DebootstrapChroot In addition to the base system packages, you'll need to install in the chroot environment any packages needed for building wxWidgets (compilers, make, autoconf, gtk and image libs, lib-dev's, python, python-dev, etc.) as well as the packages listed in the next section. Build Packages -------------- There are a number of helper packages that are used when building debian packages. Here are some that I have in my chroot, there may be some others that I am not seeing at the moment: debhelper devscripts dh-make dpkg-dev fakeroot lintian diff patch Doing the Build --------------- Ok, if you are not totally confused by this point you should have a minimal source tree produced by "make debian-dist" that is accessible by your chroot or other minimal install system. (Unless you are only making packages for yourself, then doing the build on in your main desktop environment would be okay.) The first step is to chdir to the top level of this source tree. If you haven't already you'll want to edit debian/changelog to make an entry for the current build. If the version number is changing since the last build then you'll need a whole new section. If you are just updating something in the same version then you can just get by with editing the current changelog entry. The 'dch' tool can be used to open the file in an editor with the cursor positioned for you. If you use 'dch -i' then it will create a new changelog entry for you with the proper syntax. Don't forget to copy this file back to your CVS workspace if appropriate. Our debian/control file is generated from debian/control.in, so you can force it to be created now by running the following. You may want to do this to verify its contents before proceeding with the build. ./debian/rules debian/control To run just the compile/link/etc. portions of the build you can do this: ./debian/rules build To also make a set of test binaries you can do this: fakeroot ./debian/rules binary To clean up from prior builds you can do this: fakeroot ./debian/rules clean And to automate the entire process (build, binaries, source packages, digital signing, etc.) you can do this: dpkg-buildpackage -rfakeroot When finished the binary and source packages will be left in the parent dir of the source tree. Automating the process ---------------------- The script debian/build_all automates the above stepds and builds both wxWidgets and wxPython packages in both ANSI and Unicode modes. You should do the build manually at least the first time however to make sure you have all the prerequisites and the build doesn't fail. Other Sources of Information ---------------------------- http://liw.iki.fi/liw/talks/debian-packaging-tutorial.pdf http://women.alioth.debian.org/wiki/index.php/English/BuildingTutorial http://women.alioth.debian.org/wiki/index.php/English/AdvancedBuildingTips http://www.wiggy.net/presentations/2001/DebianWalkThrough/handouts/handouts.html http://www.debian.org/doc/manuals/maint-guide/index.en.html http://www.isotton.com/debian/docs/repository-howto/repository-howto.html