Inkscape Wiki - User contributions [en]

Creating Inkscape distributions

2014-06-22T21:54:13Z

Theadib: update information for building and packaging for win32 platform

{{Other languages|en=Creating Inkscape distributions}}

== Creating Dists of Inkscape ==

Those who wish to produce packaged releases of inkscape are welcome to do so.
If it is packages changes that you've made to the official release, please select a version name that distinguishes it from the official version, to avoid confusion. For example, “inkscape-0.35-johndoe.tar.gz”. Please consider distributing your changes as a patch rather than as a full distribution, as patches tend to be easier to maintain.

Inkscape's release process works like this:

# Chill - Wrap up development work
# Frost - Feature work should be complete. Bug Hunt
# Feature Freeze - Critical bug fixing
# Hard Freeze - Two freeze wardens are named. All development must be done as patches submitted to the freeze wardens for review and integration.
# Branch - The codebase is tagged and branched. Final release tarball is posted. The codebase is returned to regular open development.
# Packaging - Three days are allowed for creating release dists (rpm's, deb's, exe's, and autopackages).
# Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites. Our Freshmeat record is updated.

=== Feature Freeze Mode ===

In the run-up to [[CreatingDists]], for a short time preceding the tagging of the release it's a good idea to hold off on adding new features or doing other major changes like architectural changes to the code that might decrease its stability. Whether a change is minor enough to be “ok” is left to the developer's judgement, and they're trusted to be conservative and careful.

The most useful activity to do during a feature freeze is to locate and/or fix bugs that produce crashes, and to do so with the smallest amount of change to the codebase possible. If a “proper” fix requires architectural changes or redesign of the code, consider writing that up as a post-release task.

-----

It might be useful to branch off a release branch a week before making the release. Hopefully most people using CVS would switch to this branch at this time. Then only bug fixes can go into that branch. --[[Ted]]

=== Branching the release candidate ===

Before release, a branch should have been be created for that release in the form RELEASE_<major>_<minor>_BRANCH. For example, 0.38 should have a branch called RELEASE_0_38_BRANCH.

Minor fixes and code review can then be performed on that branch before the final release; it also permits making future point releases easily (if necessary).

To create the release branch, do the following:

<pre>svn copy https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_38_BRANCH</pre>

To check out this branch:

<pre>svn checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_38_BRANCH inkscape-0.38-branch</pre>

Once the release is deemed ready a distribution tarball should be created as below.

=== Creating a distribution source tarball package ===

On the release branch (NOT ON HEAD):

* Set the version name via the file configure.ac in the AC_INIT() macro, CMakeList.txt, packaging/win32/inkscape.nsi, src/inkscape.rc, src/inkview.rc, src/inkscape-x64.rc, src/inkview-x64.rc build-lx.xml, build-x64.xml and build.xml
* Run `perl packaging/mkNEWS 0.91 > NEWS` to add the release notes into the NEWS file in the release branch. This command requires perl and w3m. Don't forget to replace 0.91 with the correct version number. The NEWS file may need some manual cleanup, so do a quick review of it.
* Run ./autogen.sh --no-configure && ./configure (with any flags, e.g. CXXFLAGS=).
* Run “cd src && make helper/sp-marshal.h helper/sp-marshal.cpp”, then do “bzr status” to check for anything strange (e.g. source files accidentally added or removed)
* Run “bzr commit -m 'update for release'” to commit the changed configure.ac and other files to the branch.
* Run "cd po && make update-po" to update the translation files. This especially must be done when declaring string freeze. Then "bzr commit -m'update translations'" for these changes as well.
* Run "make dist"
* This should produce inkscape-VERSION.tar.gz, inkscape-VERSION.tar.bz2, and inkscape-VERSION.zip
* In SourceForge's admin interface create a VERSION folder, and then upload these three packages.
* Tag the release in bzr. Release tags should be in the form INKSCAPE_<major>_<minor>_<point>. A non-point-release like 0.91 would get the tag INKSCAPE_0_91_0, 0.91.1 would get the tag INKSCAPE_0_91_1, and so on. Pre-releases are tagged like INKSCAPE_0_91_PRE0.

On HEAD:

* After establishing the release branch, change the master trunk's configure.ac, inkscape.rc, inkview.rc to reflect the new future version, 0.91+devel.

=== GPG signing Tarballs ===

Downstream packagers are asking for and may soon demand gpg signed tarballs. For Fedora, this is not a requirement, but does ease acceptance of packages. It also shows we are doing “The Right Thing”. md5sums are not foolproof.

* To create a gpg signed tarball:

<pre>$gpg -u packager@foo.net --armor --output tarball.sig --detach-sig tarball.tar.gz</pre>

* To verify :

<pre>$gpg --verify ./tarball.asc ./tarball.tar.gz</pre>

Of course, this step doesn't mean much in practice unless people have a trust path to your key. Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).

:Where are the public keys matching these sig's posted?

=== Creating a Windows Distro ===
Inkscape/sodipodi has always been
buildable on Win32. The problem with the sodipodi and original inkscape build, though,
was that the Win32 builder had to download and configure
a lot of things to make it to work. Mingw, MSYS, automake,
autoconf, pkg-config, the codepages, etc. He would spend more
time on THAT than the actual code.

What a pain for the average developer/user who merely wants
to make Inkscape do what he wants it to do. Why waste
days and days getting it to compile, when the developer
would rather be working on the program itself?

So we spent several weeks collecting libraries, building others,
installing the codepages into the source (which we can delete soon
because of Pango) and creating a set of clean makefiles
that work on Win9x, NT, XP, and the cross-compiler.
It is a bit more work for people like me, but hopefully it
attains its goal of saving a lot of work for other people.

Also, remember that on Unix/Linux, $PREFIX is commonly
/usr/local or /usr or something like that. In windows, all of
a program's files are typically located in their own directory. So all
of the files are located relative to “.”. Actually, relative to
the .exe that is currently running.

.....anyway, just wanted to explain that there is a reason
for the Win32 build to be constructed in such a manner,
and that we haven't just been arbitrary.

The version numbers in the FILEVERSION and PRODUCTVERSION fields within inkscape.rc and inkview.rc need to be updated to reflect the current version number of the release.

Once the tree is built ('''mingwenv''', '''g++ buildtool.cpp -O3 -g0 -fopenmp -o btool''' and '''btool''') into the “inkscape” directory, the [http://nsis.sourceforge.net/ NSIS] installer script “inkscape.nsi” can be run to create the self-extracting win32 installer.

The Windows download package should be named according to the following scheme:

inkscape-$RELEASE-$PKG.$WINVER.exe

Where $WINVER is the required Windows version, e.g. “win32”. For example:

inkscape-0.37-1.win32.exe

The new wix installer in the packaging/wix directory creates msi packages. Follow the instructions in the README file. The installer scripts parse version information from the src/inkscape.rc and inkscape/inkscape.exe file. Depending on the architecture build the generated packed is named as:

inkscape-$RELEASE.msi or
inkscape-$RELEASE-x64.msi

=== Creating a Debian .deb ===

The article [[CompilingDebian]] provides a makefile to download a tarball and build a debian package therefrom.

=== Creating a distribution RPM ===

Method A:
# do as above for tarball, or download the release tarball
# login as root
# rpmbuild -tb inkscape-x.x.tar.gz
# Your RPMs will be in /usr/src/rpm[[/RPMS]] (/usr/src/redhat on RH systems)
# RPMs should be GPG signed

Method B:
# do as above for tarball, or download the release tarball
# mkdir ~/rpm
# Copy the tarball to ~/rpm/SOURCES/
# Copy the inkscape.spec from the tarball to ~/rpm/SPECS/inkscape.spec
# rpmbuild -ba ~/rpm/SPECS/inkscape.spec
# Your RPMs will be in ~/rpm/RPMS and ~/rpm/SRPMS
# RPMs should be GPG signed

The rpm should be named according to the following pattern:

inkscape-$RELEASE-$PKG.$DISTRO.$ARCH.rpm

Where:

$RELEASE: the Inkscape release number, such as “0.37”, “0.36.2”, etc.
The third number should be omitted if it is 0. (I.e., 0.37 instead of 0.37.0)

$PKG: A version number for your package. Use a value of 1 for your package, and increment it if you
need to update the released package for some reason.

$DISTRO: The name and an indicator of the version number for the distro. E.g.,
rh71, rh90, mdk91, suse90, fc1, etc. No need to be too exhaustive with the distro versions;
for a given brand of distro it's probably enough to have a reasonably “modern” release
and an older one for legacy support. For instance, rh71 and rh90.

$ARCH: The architecture that the package was built on. E.g., i686, i386, athlon, ppc, etc.
Don't bother with i586 - either i386 or i686 is preferred. The i386 packages will run on Cyrix
and K-6.

Examples:

inkscape-0.37-1.mdk80.i386.rpm
inkscape-0.37-1.mdk80.i686.rpm
inkscape-0.37-1.mdk91.i386.rpm
inkscape-0.37-1.mdk91.i686.rpm

inkscape-0.37-1.fc1.i386.rpm
inkscape-0.37-1.fc1.i686.rpm
inkscape-0.37-1.fc1.athlon.rpm
inkscape-0.37-1.fc1.ppc.rpm

For creating spec files, feel free to list yourself as the packager, but please use
inkscape-devel@lists.sourceforge.net as the contact email address, to ensure that
questions/complaints about the RPM go to the official support channel.

==== Patching RPMs ====

Occasionally, the RPM will not build without some modifications. If the problem is serious enough that it affects every packaging format, this could signal a need to do a point release, but usually you can just add a patch specifically for the RPM. This is what RPM is for, after all. :-)

Here's how to do it:

1. Create a copy of the source tree, with the modifications needed to correct the issue.
2. Generate a patch like this:

$ diff -uNr package-1.0/ package-1.0p/ > ../SOURCES/package-1.0-my.patch

3. Next add the patch to the RPM. In the specfile at %_topdir/SPECS/package.spec, add a line like this at the top of the file:

Patch0: package-1.0-my.patch

Then further down add a line after the %setup section, like this:

%prep
%setup ...
%patch0 -p1

It's a very good idea to split up changes into discrete patches, giving each a different number (they don't have to be consecutively numbered). Also, be sure to upload the patch(es) to the patch tracker so they'll get into the codebase for the next release.

Then rebuild the package like this:

rpmbuild -ba SPECS/package.spec

=== Signing your package ===

First, you need to have a public/private keypair. This can be generated with gpg using 'gpg --gen-key'.

To add a signature to an extisting package, use the command rpm --addsign /path/to/package.rpm To sign in the process of building a package, use rpmbuild -bb --sign

To check the signature on a package, use rpm --checksig.

=== Releasing Dists on the [[SourceForge]] File Release Tool ===

To release a file: (You need Release Tech permission for your Inkscape account)

* ftp upload.sf.net (anonymous/anonymous)
* cd incoming
* mput filename
* go to Admin -> File Releases
* scroll to the bottom and click [Add Release] to the inkscape item
* Enter 0.35 in the box & click “Create this Release”
* Fill in the form, checkbox the file you uploaded in (c)
* It won't give you a clear “success” message, but you can check it got in right by going to the Files list. You can then edit any of the info you entered, to make it more correct.

Also see [[CVSNamingConventions]] if you are making a release.

=== Announcing Releases ===

When you cut a release, send a copy of the release notes as an announcement to inkscape-announce@lists.sourceforge.net.
If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list. This is done by a list admin such as Bryce Harrington.

'''[[AnnouncingReleases]]''' - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).

=== Updating Website Collateral ===

When a new release is cut, there are several pieces of info that need to be added to the website:

* Add a news item on front page
* Review/revise FAQ
* Review/revise Roadmap
* Add or revise Screenshots (if appropriate)
* doc directory: Add the manpage for the release, update doc/keys.html file, and change the corresponding version number(s) in doc/index.php.
** From the shell on inkscape.org, cd to /home/inkscape/inkscape_web and run the command “(cd ../inkscape; svn update; chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html”.

[[Category:Help Wanted]]

Creating Inkscape distributions

2014-06-22T21:46:03Z

Theadib: review the files to be changed for updating version number

{{Other languages|en=Creating Inkscape distributions}}

== Creating Dists of Inkscape ==

Those who wish to produce packaged releases of inkscape are welcome to do so.
If it is packages changes that you've made to the official release, please select a version name that distinguishes it from the official version, to avoid confusion. For example, “inkscape-0.35-johndoe.tar.gz”. Please consider distributing your changes as a patch rather than as a full distribution, as patches tend to be easier to maintain.

Inkscape's release process works like this:

# Chill - Wrap up development work
# Frost - Feature work should be complete. Bug Hunt
# Feature Freeze - Critical bug fixing
# Hard Freeze - Two freeze wardens are named. All development must be done as patches submitted to the freeze wardens for review and integration.
# Branch - The codebase is tagged and branched. Final release tarball is posted. The codebase is returned to regular open development.
# Packaging - Three days are allowed for creating release dists (rpm's, deb's, exe's, and autopackages).
# Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites. Our Freshmeat record is updated.

=== Feature Freeze Mode ===

In the run-up to [[CreatingDists]], for a short time preceding the tagging of the release it's a good idea to hold off on adding new features or doing other major changes like architectural changes to the code that might decrease its stability. Whether a change is minor enough to be “ok” is left to the developer's judgement, and they're trusted to be conservative and careful.

The most useful activity to do during a feature freeze is to locate and/or fix bugs that produce crashes, and to do so with the smallest amount of change to the codebase possible. If a “proper” fix requires architectural changes or redesign of the code, consider writing that up as a post-release task.

-----

It might be useful to branch off a release branch a week before making the release. Hopefully most people using CVS would switch to this branch at this time. Then only bug fixes can go into that branch. --[[Ted]]

=== Branching the release candidate ===

Before release, a branch should have been be created for that release in the form RELEASE_<major>_<minor>_BRANCH. For example, 0.38 should have a branch called RELEASE_0_38_BRANCH.

Minor fixes and code review can then be performed on that branch before the final release; it also permits making future point releases easily (if necessary).

To create the release branch, do the following:

<pre>svn copy https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_38_BRANCH</pre>

To check out this branch:

<pre>svn checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/RELEASE_0_38_BRANCH inkscape-0.38-branch</pre>

Once the release is deemed ready a distribution tarball should be created as below.

=== Creating a distribution source tarball package ===

On the release branch (NOT ON HEAD):

* Set the version name via the file configure.ac in the AC_INIT() macro, CMakeList.txt, packaging/win32/inkscape.nsi, src/inkscape.rc, src/inkview.rc, src/inkscape-x64.rc, src/inkview-x64.rc build-lx.xml, build-x64.xml and build.xml
* Run `perl packaging/mkNEWS 0.91 > NEWS` to add the release notes into the NEWS file in the release branch. This command requires perl and w3m. Don't forget to replace 0.91 with the correct version number. The NEWS file may need some manual cleanup, so do a quick review of it.
* Run ./autogen.sh --no-configure && ./configure (with any flags, e.g. CXXFLAGS=).
* Run “cd src && make helper/sp-marshal.h helper/sp-marshal.cpp”, then do “bzr status” to check for anything strange (e.g. source files accidentally added or removed)
* Run “bzr commit -m 'update for release'” to commit the changed configure.ac and other files to the branch.
* Run "cd po && make update-po" to update the translation files. This especially must be done when declaring string freeze. Then "bzr commit -m'update translations'" for these changes as well.
* Run "make dist"
* This should produce inkscape-VERSION.tar.gz, inkscape-VERSION.tar.bz2, and inkscape-VERSION.zip
* In SourceForge's admin interface create a VERSION folder, and then upload these three packages.
* Tag the release in bzr. Release tags should be in the form INKSCAPE_<major>_<minor>_<point>. A non-point-release like 0.91 would get the tag INKSCAPE_0_91_0, 0.91.1 would get the tag INKSCAPE_0_91_1, and so on. Pre-releases are tagged like INKSCAPE_0_91_PRE0.

On HEAD:

* After establishing the release branch, change the master trunk's configure.ac, inkscape.rc, inkview.rc to reflect the new future version, 0.91+devel.

=== GPG signing Tarballs ===

Downstream packagers are asking for and may soon demand gpg signed tarballs. For Fedora, this is not a requirement, but does ease acceptance of packages. It also shows we are doing “The Right Thing”. md5sums are not foolproof.

* To create a gpg signed tarball:

<pre>$gpg -u packager@foo.net --armor --output tarball.sig --detach-sig tarball.tar.gz</pre>

* To verify :

<pre>$gpg --verify ./tarball.asc ./tarball.tar.gz</pre>

Of course, this step doesn't mean much in practice unless people have a trust path to your key. Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).

:Where are the public keys matching these sig's posted?

=== Creating a Windows Distro ===
Inkscape/sodipodi has always been
buildable on Win32. The problem with the sodipodi and original inkscape build, though,
was that the Win32 builder had to download and configure
a lot of things to make it to work. Mingw, MSYS, automake,
autoconf, pkg-config, the codepages, etc. He would spend more
time on THAT than the actual code.

What a pain for the average developer/user who merely wants
to make Inkscape do what he wants it to do. Why waste
days and days getting it to compile, when the developer
would rather be working on the program itself?

So we spent several weeks collecting libraries, building others,
installing the codepages into the source (which we can delete soon
because of Pango) and creating a set of clean makefiles
that work on Win9x, NT, XP, and the cross-compiler.
It is a bit more work for people like me, but hopefully it
attains its goal of saving a lot of work for other people.

Also, remember that on Unix/Linux, $PREFIX is commonly
/usr/local or /usr or something like that. In windows, all of
a program's files are typically located in their own directory. So all
of the files are located relative to “.”. Actually, relative to
the .exe that is currently running.

.....anyway, just wanted to explain that there is a reason
for the Win32 build to be constructed in such a manner,
and that we haven't just been arbitrary.

The version numbers in the FILEVERSION and PRODUCTVERSION fields within inkscape.rc and inkview.rc need to be updated to reflect the current version number of the release.

Once the tree is built (“make -f Makefile.mingw” and “make -f Makefile.mingw dist-strip”) into the “inkscape” directory, the [http://nsis.sourceforge.net/ NSIS] installer script “inkscape.nsi” can be run to create the self-extracting win32 installer.

The Windows download package should be named according to the following scheme:

inkscape-$RELEASE-$PKG.$WINVER.exe

Where $WINVER is the required Windows version, e.g. “win32”. For example:

inkscape-0.37-1.win32.exe

The new wix installer in the packaging/wix directory creates msi packages. Follow the instructions in the README file. The installer scripts parse version information from the inkscape.rc file. The generated packed is named as:

inkscape-$RELEASE.msi

=== Creating a Debian .deb ===

The article [[CompilingDebian]] provides a makefile to download a tarball and build a debian package therefrom.

=== Creating a distribution RPM ===

Method A:
# do as above for tarball, or download the release tarball
# login as root
# rpmbuild -tb inkscape-x.x.tar.gz
# Your RPMs will be in /usr/src/rpm[[/RPMS]] (/usr/src/redhat on RH systems)
# RPMs should be GPG signed

Method B:
# do as above for tarball, or download the release tarball
# mkdir ~/rpm
# Copy the tarball to ~/rpm/SOURCES/
# Copy the inkscape.spec from the tarball to ~/rpm/SPECS/inkscape.spec
# rpmbuild -ba ~/rpm/SPECS/inkscape.spec
# Your RPMs will be in ~/rpm/RPMS and ~/rpm/SRPMS
# RPMs should be GPG signed

The rpm should be named according to the following pattern:

inkscape-$RELEASE-$PKG.$DISTRO.$ARCH.rpm

Where:

$RELEASE: the Inkscape release number, such as “0.37”, “0.36.2”, etc.
The third number should be omitted if it is 0. (I.e., 0.37 instead of 0.37.0)

$PKG: A version number for your package. Use a value of 1 for your package, and increment it if you
need to update the released package for some reason.

$DISTRO: The name and an indicator of the version number for the distro. E.g.,
rh71, rh90, mdk91, suse90, fc1, etc. No need to be too exhaustive with the distro versions;
for a given brand of distro it's probably enough to have a reasonably “modern” release
and an older one for legacy support. For instance, rh71 and rh90.

$ARCH: The architecture that the package was built on. E.g., i686, i386, athlon, ppc, etc.
Don't bother with i586 - either i386 or i686 is preferred. The i386 packages will run on Cyrix
and K-6.

Examples:

inkscape-0.37-1.mdk80.i386.rpm
inkscape-0.37-1.mdk80.i686.rpm
inkscape-0.37-1.mdk91.i386.rpm
inkscape-0.37-1.mdk91.i686.rpm

inkscape-0.37-1.fc1.i386.rpm
inkscape-0.37-1.fc1.i686.rpm
inkscape-0.37-1.fc1.athlon.rpm
inkscape-0.37-1.fc1.ppc.rpm

For creating spec files, feel free to list yourself as the packager, but please use
inkscape-devel@lists.sourceforge.net as the contact email address, to ensure that
questions/complaints about the RPM go to the official support channel.

==== Patching RPMs ====

Occasionally, the RPM will not build without some modifications. If the problem is serious enough that it affects every packaging format, this could signal a need to do a point release, but usually you can just add a patch specifically for the RPM. This is what RPM is for, after all. :-)

Here's how to do it:

1. Create a copy of the source tree, with the modifications needed to correct the issue.
2. Generate a patch like this:

$ diff -uNr package-1.0/ package-1.0p/ > ../SOURCES/package-1.0-my.patch

3. Next add the patch to the RPM. In the specfile at %_topdir/SPECS/package.spec, add a line like this at the top of the file:

Patch0: package-1.0-my.patch

Then further down add a line after the %setup section, like this:

%prep
%setup ...
%patch0 -p1

It's a very good idea to split up changes into discrete patches, giving each a different number (they don't have to be consecutively numbered). Also, be sure to upload the patch(es) to the patch tracker so they'll get into the codebase for the next release.

Then rebuild the package like this:

rpmbuild -ba SPECS/package.spec

=== Signing your package ===

First, you need to have a public/private keypair. This can be generated with gpg using 'gpg --gen-key'.

To add a signature to an extisting package, use the command rpm --addsign /path/to/package.rpm To sign in the process of building a package, use rpmbuild -bb --sign

To check the signature on a package, use rpm --checksig.

=== Releasing Dists on the [[SourceForge]] File Release Tool ===

To release a file: (You need Release Tech permission for your Inkscape account)

* ftp upload.sf.net (anonymous/anonymous)
* cd incoming
* mput filename
* go to Admin -> File Releases
* scroll to the bottom and click [Add Release] to the inkscape item
* Enter 0.35 in the box & click “Create this Release”
* Fill in the form, checkbox the file you uploaded in (c)
* It won't give you a clear “success” message, but you can check it got in right by going to the Files list. You can then edit any of the info you entered, to make it more correct.

Also see [[CVSNamingConventions]] if you are making a release.

=== Announcing Releases ===

When you cut a release, send a copy of the release notes as an announcement to inkscape-announce@lists.sourceforge.net.
If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list. This is done by a list admin such as Bryce Harrington.

'''[[AnnouncingReleases]]''' - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).

=== Updating Website Collateral ===

When a new release is cut, there are several pieces of info that need to be added to the website:

* Add a news item on front page
* Review/revise FAQ
* Review/revise Roadmap
* Add or revise Screenshots (if appropriate)
* doc directory: Add the manpage for the release, update doc/keys.html file, and change the corresponding version number(s) in doc/index.php.
** From the shell on inkscape.org, cd to /home/inkscape/inkscape_web and run the command “(cd ../inkscape; svn update; chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html”.

[[Category:Help Wanted]]

Compiling Inkscape on Windows 32-bit

2011-01-20T20:14:55Z

Theadib: /* Setting up the build environment */

Inkscape was originally written for Linux, but it has been ported to other platforms, including Windows. Since Windows is not POSIX compliant and doesn't have several features useful to developers (like package management), compiling Inkscape on Windows is more tedious than on Linux, but perfectly possible.

==Setting up the build environment==

To develop Inkscape, you will need the following things:

* [http://wiki.bazaar.canonical.com/WindowsDownloads Bazaar]
* [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] programs: puttygen.exe and pageant.exe
* [http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.5.1.exe/download TDM-MinGW 4.5.1]
* [http://sourceforge.net/projects/nsis/files/NSIS%202/2.46/nsis-2.46-setup.exe/download NSIS 2.46]
* Launchpad account

===Install the compiler===
Run the TDM-MinGW installer and install it in a path that doesn't contain spaces, preferably C:\mingw. If you install it into another path, set the environment variable MINGW_PATH to the TDM-MinGW installation directory, e.g. the one containing <tt>README-tdm-gcc.txt</tt> (right click My Computer -> Properties -> Advanced -> Environment Variables). During the installation, enable the "openmp support" checkbox from the components list or choose to install all packages (option "TDM-GCC recommended, All Packages" in the TDM-GCC 4.5.1 installer).

If you have TDM-GCC 4.5.1, copy the file "\bin\libgomp-1.dll" "\lib\gcc\mingw32\bin\libgomp-1.dll" (paths relative to your installation directory).

===Create your Launchpad account===
If you do not have an SSH public/private key pair to identify yourself:
*run the program puttygen.exe to generate an SSH key
*save both its parts.
Log into your Launchpad account, go to your profile page and add the public part of the generated key to the list of SSH keys. Run the program pageant.exe (you can add it to Autorun). A tray icon should appear. Right click it, select "Add Key" and pick the private key file you have just generated from the dialog. Note that you need to repeat this after every login whenever you want to access Launchpad.

Now set up Bazaar. First tell it who you are, then associate with your Launchpad account. You need to use the account name (e.g. johnq), not the display name.(John Q. Public).

C:\> bzr whoami "''Your Name'' <''your_real_email@example.com''>"
C:\> bzr launchpad-login ''your_launchpad_account''

===Install the developer libraries===
Check out Inkscape Devlibs into C:\devlibs. If you check them out elsewhere, set the environment variable DEVLIBS_PATH to the path where they are. Devlibs are a bundle of all the libraries needed to compile Inkscape. If you experience any problems, make sure you have an up to date copy of those libraries and an up to date checkout of Inkscape source. To reduce the size of the download, pass the <tt>--lightweight</tt> parameter.

C:\> bzr checkout --lightweight lp:inkscape-devlibs devlibs

To update devlibs:

C:\devlibs> bzr update

All Inkscape developers can commit to the devlibs trunk. Advanced information about Devlibs, mainy useful when you want to update them to newly released versions of upstream libraries, is available here: [[Inkscape Devlibs]].
You can see some infomation from [https://launchpad.net/inkscape-devlibs launchpad:inkscape-devlibs] and [http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs/trunk/files trunk/files].

== Obtaining Inkscape source code ==

You can obtain released Inkscape source from a tarball. Since version 0.47 they are hosted on [https://launchpad.net/inkscape Inkscape's Launchpad page]. There are ready-made installers provided, so there's usually little reason to compile the stable version yourself.

To obtain cutting edge code, check out Inkscape source from the Bazaar repository. You can also use the TortoiseBZR shell extensions to do this. The recommended way is to first create a shared repository, then check out the Inkscape branch into that shared repository. Using this setup, branching will be a lot faster.

C:\src\inkscape> bzr init-repo --rich-root
C:\src\inkscape> bzr checkout lp:inkscape trunk

If you don't want to create any branches, you can skip the shared repository step.

C:\src> bzr checkout lp:inkscape

'''IMPORTANT:''' make sure that the path to your Inkscape source checkout does not contain spaces. Unix tools do not like them and you will end up with a lot of error messages about missing files.

== Building Inkscape ==

Open the command prompt, navigate to the directory with Inkscape sources. First set up some environmental variables. You only need to do this once per console session.

C:\src\inkscape\trunk> mingwenv

Now compile the build tool. Try the second command if the first one fails.

C:\src\inkscape\trunk> g++ buildtool.cpp -o btool
C:\src\inkscape\trunk> g++ -DNEED_GETTIMEOFDAY buildtool.cpp -o btool

Finally initiate the compilation. Get a coffee or take your dog out for a walk, because it will take a rather long time.

C:\src\inkscape\trunk> btool

Once everything is done, there should be an <tt>inkscape</tt> directory that contains the Inkscape executable and libraries needed to run it.

== Rebuilding ==

If you have only changed a few files and want to rebuild, delete the <tt>inkscape</tt> directory and run <tt>btool</tt> again.

To rebuild from scratch, execute the following sequence of commands:
C:\src\inkscape\trunk> btool clean
C:\src\inkscape\trunk> btool

== Dealing With Build Errors ==
Feel free to add any questions or answers you have in here;

'''Q''' - My firewall software (Comodo's Defense+ component or similar) stopped the process continuing to the next step in the build, because I wasn't there to permit an action and it timed out. What can I do?

'''A1''' - The best thing is to disable stuff like Defense+ (put it in learning mode works) because it will stop any process that is not approved, and building makes new files which can't be approved before they're built. Disabling Comodo's Defense+ does not disable your firewall, either inbound or outbound, but just the part that scans every application for suspicious operations. Other firewalls etc may vary.

'''A2''' - If that doesn't suit, often you can simply run btool again and wait for Defense+ (or similar) to ask for approval for the process, and it will then continue as normal with the build. But remember that approving all the processes involved in the build process once doesn't mean they will all slip through next time.

'''A3''' - This is the more complex way to continue, but may help if you have problems with A2. If you know the stage the process was meant to be up to (look at the output in the command windows and compare to the stages in the ''build.xml'' file), you can start again from there.

You may see something like this in the command window;
=============================
## Target : link : link objects and library to create executable
---- task : rc
============ cmd ============
windres -o build/inkres.o --include-dir=src src/inkscape.rc
=============================
---- task : link
This will likely be followed by an error message. This means you were at the ''link'' stage

Now simply type;
...>btool ''stage''
Or in this case
...>btool link
And the build will continue from there.

After this, you will probably have to step through the remaining stages manually, one by one. The stages can include (see build.xml, where each stage is labelled 'target name="''target''"') ''init'', ''touchabout'', ''compile'', ''java'', ''lib'', ''i18n'', ''link'', ''linkinkview'', ''dist'', ''dist-all'', ''clean''.

'''Q''' - How do I rebuild just one ''file.o'' file? For instance if one particular file has gone wrong, or I want to try patching just one part of the code.

'''A''' - To find the right command for building any particular file in Inkscape, just look in the compile.lst after you have used btool once. Search for the name of the particular file (eg: print.cpp) and you will find the command used to compile it. You'll need to paste this into a text file, remove any carriage reurns and then paste that onto the command line.

'''Q''' - After I patched a file, I left a backup of the old file in the same directory called Copy of{filename}.cpp. The compiler complains about this file when building and stops.

'''A''' - Do not leave anything with a suffix .cpp in the source directories, apart from the original (or patched) source files. The build tool will try to compile everything ending in .cpp and will complain. If you backup an old file in the same directory before patching, call it {filename}.cpp.old or similar.

'''Q''' - I think I followed the instruction above. What could have caused the compiling error like this for src/extension/internal/pdfinput/pdf-parser.cpp?

src/extension/internal/pdfinput/pdf-parser.cpp:2248: error: no matching function for call to 'GfxFont::getNextChar(char*&, int&, CharCode*, Unicode [8], int, int*, double*, double*, double*, double*)'

Same error for line 2297 as well.

=== For more information ===
There is some old information on building Inkscape with either Mingw on Windows, or a cross-compiler on Linux, at http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html
and old files mey be
http://inkscape.modevia.com/win32libs/
== Creating an installer ==

To create the setup package you need the NSIS installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\inkscape\ directory.
Open the ...\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

== Note about Unicode ==

The GTK stack depends on functions only present in NT-based Windows (2000 and later). Therefore, Inkscape code can assume that Unicode functions from the Windows API (like GetCommandLineW) are always present. Note however that you should use the GLib/GTK functions rather the Windows API whenever possible.

=See also=
*[[Compiling Inkscape]]

[[Category:Developer Documentation]]

PerformanceMeasures

2009-09-30T20:00:57Z

Theadib: /* build times for Inkscape-0.47pre3.tar.gz */

[[Category:Developer Documentation]]

== Performance Measures ==

=== build times ===

==== build times for Inkscape-0.47pre3.tar.gz ====
* my machine: Laptop DELL latitude D520 - E5500 Dualcore@1.6GHz 3329 bogomips 2GBRAM
** Linux Ubuntu9.04: "time make -j2" '''real 22m38 user36m21 sys 2m57'''
** Windows XP: "g++ buildtool.cpp -O2 -g0 -mtune=prescott" -o btool" "btool clean" "btool" '''46m57'''

* uwesch's machine: Laptop HP nx9420 T7400 Dualcore@2.16GHz 2GB RAM
** Windows 7: "g++ buildtool.cpp -O2 -g0 -mtune=prescott" -o btool" "btool clean" "btool" '''48m52'''

* my machine: Destop - E7200 Dualcore@2.5GHz 5066 bogomips 2GBRAM
** Linux Ubuntu9.04: "time make -j2" '''real 13m7 user 23m15 sys 1m53'''

Multipage

2009-04-23T13:05:28Z

Theadib:

== Multipage support ==
* this feature is currently not implemented
* this page describes how the feature should be implemented
* there should be multiple pages within a document
* problem arises when saving to singlepage file formats (jpg, png, etc)
* SVG does not support multipage per se, but upcomming SVG will do [[http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html see W3.org]]
* There are two contrary implementattions in the real world:
** distribute pages around the graphics elements - the Adobe way
** distribute graphics elements around the pages - how Corel does it and how SVG propose it

== multipage in the SVG standard ==
* All pages are contained within a single pageSet element. A pageSet may contain any number of page elements. Each page element defines a single container of graphical objects.
* In a screen-based user agent, only one page element is displayed at any time on the main canvas.
* The SVG content typically defines a page dimension or aspect ratio in the topmost svg element and its viewBox. The viewBox transformation applies to printed SVG in the same way as screen display.
* The orientation of each page element can be controlled by the page-orientation property. This enables the content to define whether a portrait or landscape mode is used for display and printing.

== multipage ala Corel ==
* there is a list of pages as tabs on the lower side of the drawing window
* all pages share the same page properties
* a '''master page''' contains elements that are visible on all other pages: drawings, markers
* in an object browser pages and layers are integrated
* see a screenshot [[http://wiki.inkscape.org/wiki/images/Corel_pages.PNG here]]

== Multi-page tool(similar to Artboard tool on adobe illustrator cs4). ==
* see this adobe tutorial [[http://www.adobe.com/designcenter/illustrator/articles/lrvid4016_ai.html here]]
* there is an [[http://www.vimeo.com/2503097 video]] by Valessio Brito presenting an UI mockup how multipage can be handled in inkscape
== implementation ==
* see this [http://www.nabble.com/Multipage-plan-td16394431.html thread]
* all export dialogues must becom extra properties to handle multiple pages, in order to specify not only the elements but also the pages to be exported

Multipage

2009-04-23T13:04:47Z

Theadib: /* multipage in the SVG standard */

== Multipage support ==
* this feature is currently not implemented
* this page describes how the feature should be implemented
* there should be multiple pages within a document
* problem arises when saving to singlepage file formats (jpg, png, etc)
* SVG does not support multipage per se, but upcomming SVG will do [[http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html see W3.org]]

== multipage in the SVG standard ==
* All pages are contained within a single pageSet element. A pageSet may contain any number of page elements. Each page element defines a single container of graphical objects.
* In a screen-based user agent, only one page element is displayed at any time on the main canvas.
* The SVG content typically defines a page dimension or aspect ratio in the topmost svg element and its viewBox. The viewBox transformation applies to printed SVG in the same way as screen display.
* The orientation of each page element can be controlled by the page-orientation property. This enables the content to define whether a portrait or landscape mode is used for display and printing.
* There are two contrary implementattions in the real world:
** distribute pages around the graphics elements - the Adobe way
** distribute graphics elements around the pages - how Corel does it and how SVG propose it

== multipage ala Corel ==
* there is a list of pages as tabs on the lower side of the drawing window
* all pages share the same page properties
* a '''master page''' contains elements that are visible on all other pages: drawings, markers
* in an object browser pages and layers are integrated
* see a screenshot [[http://wiki.inkscape.org/wiki/images/Corel_pages.PNG here]]

== Multi-page tool(similar to Artboard tool on adobe illustrator cs4). ==
* see this adobe tutorial [[http://www.adobe.com/designcenter/illustrator/articles/lrvid4016_ai.html here]]
* there is an [[http://www.vimeo.com/2503097 video]] by Valessio Brito presenting an UI mockup how multipage can be handled in inkscape
== implementation ==
* see this [http://www.nabble.com/Multipage-plan-td16394431.html thread]
* all export dialogues must becom extra properties to handle multiple pages, in order to specify not only the elements but also the pages to be exported

Multipage

2009-04-23T13:02:40Z

Theadib:

== Multipage support ==
* this feature is currently not implemented
* this page describes how the feature should be implemented
* there should be multiple pages within a document
* problem arises when saving to singlepage file formats (jpg, png, etc)
* SVG does not support multipage per se, but upcomming SVG will do [[http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html see W3.org]]

== multipage in the SVG standard ==
* All pages are contained within a single pageSet element. A pageSet may contain any number of page elements. Each page element defines a single container of graphical objects.
* In a screen-based user agent, only one page element is displayed at any time on the main canvas.
* The SVG content typically defines a page dimension or aspect ratio in the topmost svg element and its viewBox. The viewBox transformation applies to printed SVG in the same way as screen display.
* The orientation of each page element can be controlled by the page-orientation property. This enables the content to define whether a portrait or landscape mode is used for display and printing.
* There are two contrary implementattions in the real world:
* distribute pages around the graphics elements - the Adobe way
* distribute graphics elements around the pages - how Corel does it and how SVG propose it

== multipage ala Corel ==
* there is a list of pages as tabs on the lower side of the drawing window
* all pages share the same page properties
* a '''master page''' contains elements that are visible on all other pages: drawings, markers
* in an object browser pages and layers are integrated
* see a screenshot [[http://wiki.inkscape.org/wiki/images/Corel_pages.PNG here]]

== Multi-page tool(similar to Artboard tool on adobe illustrator cs4). ==
* see this adobe tutorial [[http://www.adobe.com/designcenter/illustrator/articles/lrvid4016_ai.html here]]
* there is an [[http://www.vimeo.com/2503097 video]] by Valessio Brito presenting an UI mockup how multipage can be handled in inkscape
== implementation ==
* see this [http://www.nabble.com/Multipage-plan-td16394431.html thread]
* all export dialogues must becom extra properties to handle multiple pages, in order to specify not only the elements but also the pages to be exported

MultiplePages

2009-04-23T12:43:32Z

Theadib: /* Multiple Pages support */

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

PLease go to [[Multipage]]

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2009-04-23T12:41:51Z

Theadib: /* Multiple Pages support */

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

PLease go to [[Multipage this page]]

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2009-04-23T12:41:36Z

Theadib: /* Multiple Pages support */

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

PLease go to [Multipage this page]

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2009-04-23T12:41:07Z

Theadib: /* Multiple Pages support */

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

PLease go to [Multipage]

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2009-04-23T12:40:41Z

Theadib: /* Multiple Pages support */

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

PLease go to [MultiplePages]

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2009-04-23T12:40:21Z

Theadib: /* Multiple Pages support */

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

PLease go to MultiplePages

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

Multipage

2009-04-23T12:38:40Z

Theadib:

== Multipage support ==
* this feature is currently not implemented
* this page describes how the feature should be implemented
* there should be multiple pages within a document
* problem arises when saving to singlepage file formats (jpg, png, etc)
* SVG does not support multipage per se, but upcomming SVG will do [[http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html see W3.org]]

== multipage in the SVG standard ==
* All pages are contained within a single pageSet element. A pageSet may contain any number of page elements. Each page element defines a single container of graphical objects.
* In a screen-based user agent, only one page element is displayed at any time on the main canvas.
* The SVG content typically defines a page dimension or aspect ratio in the topmost svg element and its viewBox. The viewBox transformation applies to printed SVG in the same way as screen display.
* The orientation of each page element can be controlled by the page-orientation property. This enables the content to define whether a portrait or landscape mode is used for display and printing.

== multipage ala Corel ==
* there is a list of pages as tabs on the lower side of the drawing window
* all pages share the same page properties
* a '''master page''' contains elements that are visible on all other pages: drawings, markers
* in an object browser pages and layers are integrated
* see a screenshot [[http://wiki.inkscape.org/wiki/images/Corel_pages.PNG here]]

== Multi-page tool(similar to Artboard tool on adobe illustrator cs4). ==
* see this adobe tutorial [[http://www.adobe.com/designcenter/illustrator/articles/lrvid4016_ai.html here]]
* there is an [[http://www.vimeo.com/2503097 video]] by Valessio Brito presenting an UI mockup how multipage can be handled in inkscape
== implementation ==
* see this [http://www.nabble.com/Multipage-plan-td16394431.html thread]
* all export dialogues must becom extra properties to handle multiple pages, in order to specify not only the elements but also the pages to be exported

MultiplePages

2008-12-14T21:08:11Z

Theadib:

[[Category:Developer Discussion]]

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2008-12-14T21:05:44Z

Theadib: /* Multiple Pages support */

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

see also [http://www.nabble.com/Multipage-plan-td16394431.html Multiple pages plan by bulia byak]

MultiplePages

2008-12-14T21:03:41Z

Theadib: /* Multiple Pages support */

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

see also http://www.nabble.com/Multipage-plan-td16394431.html

MultiplePages

2008-12-14T21:02:32Z

Theadib: /* Multiple Pages support */

== Multiple Pages support ==

there is a big demand in supporting multiple pages

Multiple Pages are known from CorelDraw, Visio, ...

This page is how to implement this feature.

see also [[http://www.nabble.com/Multipage-plan-td16394431.html]]

MultiplePages

2008-12-14T20:56:14Z

Theadib: new discussion Multiple pages support as reference to blueprint in launchpad