|
|
(42 intermediate revisions by 9 users not shown) |
Line 1: |
Line 1: |
− | This page will collect useful information to develop GnuCash on Windows. If you were looking for tips regarding '''using''' GnuCash on Windows, you should read the [[Windows|Windows page]] instead.
| + | Development on Microsoft Windows isn't really encouraged. The build environment isn't really conducive to development and many of the unit tests don't work. However, if you must... |
− | = Update January 2014 =
| |
− | For some while the instructions in this wiki page have not 'just worked' to allow the building of a windows version of gnucash.
| |
− | This is mainly because the contents of the packaging/win32 directory have not kept pace with changes to the various dependencies and
| |
− | their repositories.
| |
| | | |
− | As of January 2014 there are updated versions of the necessary files which can be used successfully to build gnucash from scratch on Windows.
| + | = GnuCash 3.0 and Later = |
− | These have not yet made it into the official repository, so there is some manual patching to be done.
| |
− | These instructions have been tested on Windows 7 (32 and 64 bit) against gnucash 2.6.0. Your mileage may vary.
| |
| | | |
− | Many thanks to Geert Janssens who did most of the necessary work.
| + | The build system for GnuCash 2.7 and later supports Windows 7 and later. The procedure is a bit simpler than for GnuCash 2.6 and earlier and provides a somewhat easier to use development environment. That doesn't mean that we ''recommend'' that you use Windows for development: GnuCash is very much a Unix program and development is much easier in a Unix environment like Linux, BSD, or MacOS. |
| | | |
− | Please note that even if you have an existing working mingw/msys environment, you are STRONGLY recommended to start again in an empty directory, and not to reuse what you have. The scripts are not clever about checking specific versions of already installed tools, and there are lots of subtle dependencies. By starting from scratch you will be using a combination of versions which has been tested together, rather than whatever happens to be the latest version in the mingw repository at the time you run.
| + | == PowerShell == |
| | | |
− | Fortunately, mingw is happy to be installed multiple times in different directories on the same machine.
| + | The build system relies heavily on Windows PowerShell. |
| | | |
− | Let's get started.
| + | :'''Windows 7:''' The PowerShell version that ships with Windows 7 by default is too old. To build GnuCash on that platform a more recent version of [https://docs.microsoft.com/en-us/powershell/scripting/install/installing-windows-powershell?view=powershell-6#upgrading-existing-windows-powershell PowerShell] should be installed. PowerShell version 5.1 is known to work well. |
| | | |
| + | Depending on your security settings you may need to enable running scripts on your computer. For this open a powershell with Administrator privilages and run: <syntaxhighlight lang="powershell">set-executionpolicy unrestricted</syntaxhighlight> |
| | | |
− | In what follows, I will assume you are using the default c:\soft directory to contain everything.
| + | == Bootstrap the build environment == |
| | | |
− | 1 Create <code>c:\soft</code>
| + | First download and run [https://github.com/Gnucash/gnucash-on-windows/blob/master/setup-mingw64.ps1 setup-mingw64.ps1]. Depending on where you want to put the development tree you may need to run PowerShell as an administrator. Once you've downloaded the script start PowerShell. You can review the script's parameters with <syntaxhighlight lang="powershell">help \path\to\setup-mingw64.ps1</syntaxhighlight> For convenience they're |
| + | * target_dir: The root directory where the build environment will be installed. The default is c:\gcdev64, but you can put it anywhere you have write privilege. |
| + | * download_dir: Defaults to target_dir\downloads. There's no requirement to have it in target_dir. |
| + | * x86_64: Set this to $true if you want to build 64-bit binaries. The default is $false, and the developers do not often try to build 64-bit binaries so doing so isn't guaranteed to work nor are the developers much inclined to prioritize fixing it if it doesn't. |
| | | |
− | 2 I have put my patches on a convenient server I run. So you can download the file [http://www.greenwheel.com/publicFiles/gnucash-windows-fixes.zip http://www.greenwheel.com/publicFiles/gnucash-windows-fixes.zip] and unpack it into <code>c:\soft\gnucash-windows-fixes</code>
| + | :'''Note:''' The help command above will only work if the security settings of your system allow this script to be run. In addition to the ''set-executionpolicy'' command above you may have to run <syntaxhighlight lang="powershell">unblock-file \path\to\setup-mingw64.ps1</syntaxhighlight> before help will work. |
| | | |
− | 3 In that directory you will find, among other things, a file
| + | Once setup-mingw64.ps1 is complete you will have an [http://www.msys2.org/ MSYS2] environment with all of the GnuCash dependencies that don't need to be built from source installed in it. |
− | bootstrap_win_dev.vbs This is a visual basic script which will automate the first stage of the process, which consists of
| |
− | * obtaining the mingw/msys compilation environment which has the necessary tools to build on windows.
| |
− | * obtaining a working version of git and using it to
| |
− | * downloading the latest gnucash source code repository
| |
| | | |
− | If for some reason you are not using c:\soft, then please edit this script to check the various paths embedded therein and change appropriately.
| + | == Running a build == |
| | | |
− | Now run the script:
| + | Next open the Start menu and navigate to MSYS2 64Bit or MSYS2 32Bit; which you want will depend upon the bitness of your Windows version. If you specified x86_64 $true to setup-mingw64.ps1 you'll want to start the mingw64 shell, otherwise the mingw32 shell. |
− | <code> cscript bootstrap_win_dev.vbs </code> | + | ;Note: Currently [2024-07] WebKitGtk is only [{{URL:SF}}projects/gnucash/files/Dependencies/ availabe] in 32-bit and won't link with a 64-bit GnuCash. |
| + | In that shell window navigate to the gnucash-on-windows.git directory in the target directory to specified to setup-mingw64.ps1. We'll use the default for the following examples. |
| + | <syntaxhighlight lang="bash"> |
| + | cd /c/gcdev64/src/gnucash-on-windows.git |
| + | TARGET=gnucash-unstable jhbuild -f jhbuildrc build |
| + | </syntaxhighlight> |
| + | One of the things setup-mingw64.ps1 did was checkout the rest of the gnucash-on-windows repository in target_dir/src/gnucash-on-windows.git. That contains a customization (python) script and a [https://developer.gnome.org/jhbuild/stable/ jhbuild] moduleset. The customization script selects one of the three GnuCash branches to build based on the value of $TARGET; the possibilities are <tt>gnucash-stable</tt> (the default), <tt>gnucash-unstable</tt> (the unstable release git branch) and <tt>gnucash-releases</tt>, which builds GnuCash from the tarball specified in gnucash.modules instead of from a git branch.The first time <tt>jhbuild build</tt> command will build GnuCash, GnuCash Docs, and all of the dependencies that Mingw-w64 doesn't provide. After that it only builds modules that need rebuilding unless you tell it otherwise; see the [https://developer.gnome.org/jhbuild/stable/ jhbuild manual] for details on controlling jhbuild. |
| | | |
− | If all goes well, you will have in c:\soft
| + | You can start a subshell with the paths to hand-compile or run GnuCash from the command line with <syntaxhighlight lang="bash">TARGET=gnucash-unstable jhbuild -f jhbuildrc shell</syntaxhighlight> This is convenient for development as one can navigate to the gnucash build directory and re-run CMake and make as necessary while developing. '''''N.B.''''' Be sure to use a programming editor that preserves line ending style; git can get really unhappy if you put the wrong kind of line endings into a file. |
− | * an \mingw directory containing a very small part of mingw and msys ( just enough to get going )
| |
− | * a gnucash.git git repo containing the latest version of the gnucash source tree
| |
| | | |
| + | To build a package for installation there's a PowerShell script called <tt>gnucash-on-windows.git\bundle-gnucash.ps1</tt> and an automation script, <tt>gnucash-on-windows.git\buildserver\build_package.ps1</tt> suitable for use with the Task Scheduler for periodic builds. Each includes documentation accessible with PowerShell's <tt>help</tt> command, e.g. <syntaxhighlight lang="powershell">help bundle-gnucash.ps1</syntaxhighlight> |
| | | |
− | 4. Now, enter the msys environment by doing:
| + | Note that <tt>build_package.ps1</tt> also takes care of updating the gnucash-on-windows repository and that <tt>jhbuild build</tt> will update the gnucash repository; you can do so manually with git from within the Mingw shell. SSH works, just set up your ~/.ssh directory with the necessary keys and config file. |
− | cd c:\soft\mingw\msys\1.0
| |
− | msys.bat
| |
| | | |
− | This should bring up an msys console which behaves like a cut down unix shell.
| + | You may find the [https://github.com/msys2/msys2/wiki MSys2 Wiki] and [https://mingw-w64.org/doku.php/documentation Mingw-w64 Documentation] helpful. |
− | The c:\soft directory is now called /c/soft
| |
| | | |
− | cd /c/soft/gnucash.git | + | == Debugging a build == |
| + | GDB can be used on windows without too much effort. Usually it's better to attach to an already running process instead of trying to launch directly under GDB. Ctrl+C does not work as well under GDB, however this site has a workaround: [http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt Workaround for GDB Ctrl C Interrupt] |
| | | |
− | 5.
| + | Microsoft's Visual Studio Code is a possibility to integrate with gnucash and gdb for debugging. The following launch.json file can be used to debug with gdb under vscode: |
− | Now you need to patch the repository with the fixes required for Windows which haven't yet made it into the official build.
| + | <syntaxhighlight lang="json"> |
− | So run
| + | { |
− | patch -p4 </c/soft/gnucash-windows-fixes/repo.patch
| + | "version": "0.2.0", |
− | cp /c/soft/gnucash-windows-fixes/*.patch ./packaging/win32
| + | "configurations": [ |
| + | { |
| + | "name": "(gdb) launch", |
| + | "type": "cppdbg", |
| + | "request": "launch", |
| + | "program": "C:\\gcdev64\\gnucash\\maint\\inst\\bin\\gnucash.exe", |
| + | "args": [], |
| + | "stopAtEntry": true, |
| + | "cwd": "${workspaceFolder}", |
| + | "environment": [], |
| + | "externalConsole": true, |
| + | "MIMode": "gdb", |
| + | "miDebuggerPath": "C:\\gcdev64\\msys2\\mingw32\\bin\\gdb.exe", |
| + | "setupCommands": [ |
| + | { |
| + | "description": "Enable pretty-printing for gdb", |
| + | "text": "-enable-pretty-printing", |
| + | "ignoreFailures": true |
| + | } |
| + | ] |
| + | } |
| + | ] |
| + | } |
| + | </syntaxhighlight> |
| | | |
− | Note the -p4 in the patch command. This is needed to tell patch how to interpret the filenames inside the patch file
| + | = GnuCash 2.6 and Earlier = |
| | | |
− | If you find that some or all of these patches fails, it may be because since these instructions were written, some or all of the changes have made it into the repo. In that case, hopefully, the README file in /c/soft/gnucash.git/packaging/win32 will tell you what's what.
| + | '''GnuCash 2.6 is no longer being developed. This procedure is archival. Don't use it without good reason.''' |
| | | |
− | 6. Now
| + | First read the README for the [https://github.com/Gnucash/gnucash-on-windows Windows Build Environment]. You'll need to download and run [https://github.com/Gnucash/gnucash-on-windows/blob/master/bootstrap_win_dev.vbs bootstrap_win_dev.vbs], then adjust <code>gnucash-on-windows.git/custom.sh</code> to build what you want the way you want, and run |
− | cd /c/soft/gnucash.git/packaging/win32
| + | gnucash-on-windows.sh/install.sh |
| + | to build the program. |
| | | |
− | You should have a quick check of the custom.sh file in packaging/win32 which was created by step 1, and edit anything you need to change ( probably nothing ). Then simply run | + | You'll find a shell file, <code>devrc.sh</code> in <code>gnucash-on-windows.git</code>. '''Sourcing''', not running, this file |
− | ./install.sh
| + | . gnucash-on-windows.git/devrc.sh |
− | or if you want to keep all the output
| + | will set the necessary environment variables so that you can re-run the build script as usual in <code>gnucash/build</code> and run GnuCash from <code>gnucash/inst/bin</code> |
− | ./install.sh 2>&1 | tee install.out
| + | [[Category:Building]] |
− | and hope for the best.
| + | [[Category:Development]] |
− | | |
− | If everything works, you will end up with /c/soft/gnucash/inst containing various subdirectories.
| |
− | | |
− | 7. Finally, go to a normal windows command prompt ( not the msys prompt! ) and run
| |
− | c:\soft\gnucash\dist\bin\gnucash-launcher.cmd
| |
− | and hope for the best......
| |
− | | |
− | 8. NOTES - What do all these fixes do?
| |
− | The biggest change is that the new version of default.sh and install.sh know about the various dependency packages as of 2014 and not as they were some time earlier. As a result, they can actually find what they need. Most of these changes were done by Geert, but I had to make a few other changes:
| |
− | | |
− | - fix up the launcher script which is created by install_impl.sh to include some more directories
| |
− | | |
− | - deal with some errors in the default value of the relative repository directory
| |
− | | |
− | | |
− | - add handling for more types of tar archive
| |
− | | |
− | - deal with an annoying problem with the guile package whereby various dlls have the wrong names for the corresponding .scm files. I don't know whether the underlying cause was a bug in guile or a problem with libtool, but since gnucash uses a rather old version of guile, I don't expect a proper fix any time soon.
| |
− | | |
− | - don't automatically delete the build directories in /c/soft/tmp which are created by install.sh. This makes it much easier to debug gnucash as the
| |
− | source to included libraries is still around. But it will cause problems if you upgrade some libraries, as install-impl.sh assumes there's only one version of any package in tmp at once, so before doing a new build, manually clear /c/soft/tmp out completely.
| |
− | | |
− | - there is a really silly problem with gwenhywfar - the current version 4.9.0beta thinks it's still 4.7.0. This doesn't cause problems on a first build. But subsequent builds will think it's not yet there, and rebuild it unnecessarily. I haven't fixed this as it's a nuisance rather than a big problem since normally once you have gnucash built for the first time, you won't run install again.
| |
− | | |
− | - guile compiled but didn't work properly. This was traced to a problem in guile configure not correctly checking for strncasecmp and then hitting a compiler bug when optimising is turned on. The fix is to add an explicit override for that test when running guile configure.
| |
− | | |
− | The main other change is that we needed to fix the configure.ac script to handle the fact that recent versions of the gnu compiler don't understand the -no-undefined flag and bomb out if they see it in LDFLAGS, which breaks a lot of the automatic tests. But that flag is needed in the various Makefiles, since otherwise libtool won't build shared libraries properly.
| |
− | So we defer adding -no-undefined to LDFLAGS until after configure has finished its tests, but before it writes out its instructions.
| |
− | | |
− | The only other change is a minor patch to the source tree in gnc-split-reg.h where we have to explicitly undefine a couple of preprocessor values such as DELETE and DUPLICATE which were set in an included header and interfere with the chosen values of an enumeration.
| |
− | | |
− | Finally, I note that we get an unrecognised flag during configure --enable-schemas-install
| |
− | | |
− | = A bit of history =
| |
− | This page used to collect random notes from the time when we manually tried to install each and every part of the requirements. They have been moved to [[Windows/Old Notes]].
| |
− | | |
− | = Previous Instructions for an (almost) automated build =
| |
− | The instructions below are probably superseded by the new procedure above, but have been kept in for the moment, as if anything goes wrong, they may provide some clues.
| |
− | | |
− | | |
− | These instructions explain how you can compile and run GnuCash on MS Windows by yourself. This is achieved by using the mingw32/gcc compiler environment. (If you want to use the Visual Studio compiler, see the sub-project [[Cutecash]], but the instructions below must be followed first as well.)
| |
− | | |
− | We've created a shell script that will download, compile, and install
| |
− | all requirements of GnuCash on Windows and eventually GnuCash itself. Running this script will probably download ~200MB of data (but all downloaded data will be cached) and will take anything
| |
− | between 0.5 through 5 hours of time. That shell script is located in
| |
− | packaging/win32/install.sh of the gnucash [[Git]] sources.
| |
− | | |
− | ;Warning : Windows XP or more recent is required for building Gnucash using install.sh (see below). Windows 2000 support was dropped starting from GnuCash 2.3.10, older versions of Windows are not supported.
| |
− | | |
− | '''Some notes upfront'''
| |
− | :*In the following discussion, the ''c:\soft'' root folder should be replaced by whatever base folder you wish to work in. Avoid pathnames with spaces in them (so ''c:\Program Files'' is not good). Some parts of the build system don't cope well with that. If you choose a path other than ''c:\soft'', be sure to set the '''GLOBAL_DIR''' parameter to this path in custom.sh later on (see below).
| |
− | :*When installing packages in the script, it is strongly recommended that the expected locations are specified. Example: msys in ''c:\soft\msys''.
| |
− | | |
− | Before you can execute this shell script (which will do everything else automatically), you have to complete these steps manually:
| |
− | | |
− | * Download and install [http://git-scm.com/downloads git for Windows]. The preferred location to install it is $GLOBAL_DIR\git-1.7.10. If you install in another location, you will have to set GIT_DIR in custom.sh later on. The installer will add some git related items in the Windows Explorer context menus (you can access them via right-click in any directory)
| |
− | | |
− | * Choose a spot where you want to store a copy of the GnuCash repository. The default path is $GLOBAL_DIR\gnucash\repos.
| |
− | | |
− | * Create all directories in the path except the last one. For the example, make sure $GLOBAL_DIR\gnucash exists
| |
− |
| |
− | * Open a Windows explorer and go to $GLOBAL_DIR\gnucash (or your chosen location)
| |
− | | |
− | * Right-click. In the popup select '''git bash'''. This will open a command prompt.
| |
− | | |
− | * Enter: <code>git clone git://github.com/Gnucash/gnucash.git repos</code> The last part should be what you chose the call the directory to store the copy of the GnuCash repository.
| |
− | | |
− | * Go into the directory c:\soft\gnucash\packaging\win32.
| |
− | | |
− | * Take a look at the comments at the top of <tt>defaults.sh</tt> and optionally create a file <tt>custom.sh</tt> to specify directories according to your preferences; the defaults would install everything in subdirectories below c:\soft. (Note that due to shell syntax, every windows-style backslash has to be specified as two backslashes.) Do not modify defaults.sh; make a custom.sh.
| |
− | :* In here you may also specify GLOBAL_DIR, REPOS_DIR, GIT_DIR,... if you installed any of these in a non-standard directory.
| |
− | | |
− | * Download the "MSYS" package from https://sourceforge.net/downloads/mingw -> MSYS -> Base -> msys-core -> msys-1.0.11 -> MSYS-1.0.11.exe [http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.11/MSYS-1.0.11.exe/download Direct Download link]
| |
− | | |
− | * Execute this downloaded package to install it into the chosen directory, say, C:\soft\msys (which is the $MSYS_DIR variable in <tt>defaults.sh</tt>, and is strongly recommended; be sure to override $MSYS_DIR in <tt>custom.sh</tt> if you put it somewhere else.) '''NB: That's ''not'' C:\soft\msys\1.0, just C: \soft\msys!'''
| |
− | | |
− | * Download the "wget" package from https://sourceforge.net/downloads/mingw -> MSYS -> Extension -> wget -> wget-1.12-1 -> wget-1.12-1-msys-1.0.13-bin.tar.lzma [http://sourceforge.net/projects/mingw/files/MSYS/Extension/wget/wget-1.12-1/wget-1.12-1-msys-1.0.13-bin.tar.lzma/download Direct download link] and place the downloaded file in the $DOWNLOAD_DIR in <tt>defaults.sh</tt>
| |
− | | |
− | * Start the MSYS commandline shell by double-clicking the "MSYS" icon on the desktop which should have been created when you installed the MSYS package.
| |
− | | |
− | * Let the automated build begin by typing:
| |
− | | |
− | $INSTALLER_DIR/install.sh (the complete path to the install.sh)
| |
− | (e.g. /c/soft/packaging/win32/install.sh, or to save the log, | |
− | /c/soft/packaging/win32/install.sh 2>&1 | tee /c/soft/Build.txt)
| |
− | | |
− | * If you get an error about the "tools" directory not existing, just make it (i.e. $GLOBAL_DIR\tools)
| |
− | | |
− | * If you get an error about unzip not found, re-run install.sh. This is also usually the case about packages not found, after they have been installed.
| |
− | | |
− | * Some of the downloaded packages are installed through graphical installer dialogs where you can choose an installation directory. In those cases, the install.sh script will tell you in the MSYS window the installation directory that you should choose, according to your settings in <tt>defaults.sh/custom.sh</tt>. Please enter only those installation directory in the installer dialog because otherwise the install.sh script cannot find the newly installed software.
| |
− | | |
− | * If there haven't been any errors, you should be able (after several hours of compiling and installing) to start gnucash from the MSYS command line by typing
| |
− | | |
− | c:/soft/gnucash/inst/bin/gnucash
| |
− | | |
− | or even without MSYS directly by "Start"-> "Run"-> "c:\soft\gnucash\inst\bin\gnucash.bat"
| |
− | | |
− | On Windows Vista Home Premium, open a windows command prompt, "cd \soft\gnucash\inst\bin" and then type
| |
− | "gnucash-launcher.cmd"
| |
− | | |
− | * If you want to make a distribution executable, execute the following commands in MSYS, after executing install.sh described above.
| |
− | | |
− | rm -rf /c/soft/gnucash/dist
| |
− | /c/soft/packaging/dist.sh
| |
− | | |
− | * To start fresh with new package installs and cleaned out environment variables, after messing up the package installs, execute in MSYS, as for install.sh above, then restart your computer to eliminate environment variable problems such as with ACLOCAL:
| |
− | | |
− | c:/soft/packaging/win32/reset.sh
| |
− | | |
− | * To make modifications to your own source that is in
| |
− | | |
− | c:/soft/gnucash/repos/src
| |
− | | |
− | * If there HAVE been errors, then please report them in the Section [[#Problems, issues, comments|Problems, issues, comments]].
| |
− | | |
− | * When compiled from source, GnuCash will display in the default GTK Raleigh theme. The GnuCash binary installer defaults to the GTK-Wimp theme, which defers rendering of widgets to Windows for a native look-and-feel. Copy gtkrc from C:\soft\gnome\share\themes\MS-Windows\gtk-2.0 to C:\soft\gnome\etc\gtk-2.0 to change themes.
| |
− | | |
− | | |
− | Please spread the word and report back any problems you encounter. It is probably not too difficult anymore to create a full self-contained
| |
− | package of GnuCash on Windows as well! Some more information is also
| |
− | collected here on this wiki page.
| |
− | | |
− | = Working on Gnucash =
| |
− | Once you've successfully built Gnucash and all of its dependencies, it's a bit of a pain to re-run install.sh after every edit. To use <tt>make</tt> from the command prompt as usual, you need to set the following environment:
| |
− | export OLDPATH=$PATH
| |
− |
| |
− | PATH=/c/soft/autotools/bin:$PATH
| |
− | PATH=/c/soft/swig:$PATH
| |
− | PATH=$PATH:/c/soft/active-perl/ActivePerl/perl/bin
| |
− | PATH=$PATH:/c/soft/aqbanking/bin
| |
− | PATH=$PATH:/c/soft/gwenhywfar/bin
| |
− | PATH=$PATH:/c/soft/autotools/bin
| |
− | PATH=$PATH:/c/soft/enchant/bin
| |
− | PATH=$PATH:/c/soft/gmp/bin
| |
− | PATH=$PATH:/c/soft/gnome/bin
| |
− | PATH=$PATH:/c/soft/gnutls/bin
| |
− | PATH=$PATH:/c/soft/goffice/bin
| |
− | PATH=$PATH:/c/soft/guile/bin
| |
− | PATH=$PATH:/c/soft/libdbi/bin
| |
− | PATH=$PATH:/c/soft/libgsf/bin
| |
− | PATH=$PATH:/c/soft/libofx/bin
| |
− | PATH=$PATH:/c/soft/libsoup/bin
| |
− | PATH=$PATH:/c/soft/libxslt/bin
| |
− | PATH=$PATH:/c/soft/mysql/bin
| |
− | PATH=$PATH:/c/soft/mysql/lib
| |
− | PATH=$PATH:/c/soft/opensp/bin
| |
− | PATH=$PATH:/c/soft/pcre/bin
| |
− | PATH=$PATH:/c/soft/pgsql/bin
| |
− | PATH=$PATH:/c/soft/pgsql/lib
| |
− | PATH=$PATH:/c/soft/regex/bin
| |
− | PATH=$PATH:/c/soft/sqlite3/bin
| |
− | PATH=$PATH:/c/soft/webkit/bin
| |
− |
| |
− | export PATH
| |
− |
| |
− | export LTDL_LIBRARY_PATH=/c/soft/gnucash/inst/lib
| |
− | export GNOME2_PATH=/c/soft/gnome
| |
− | export INTLTOOL_PERL=/c/soft/active-perl/ActivePerl/perl/bin/perl
| |
− | export GIT_CMD=/c/soft/git/git
| |
− | export ACLOCAL_FLAGS="-I/c/soft/guile/share/aclocal -I/c/soft/gwenhywfar/share/aclocal -I/c/soft/aqbanking/share/aclocal -I/c/soft/autotools/share/aclocal -I/c/soft/gnome/share/aclocal -I/c/soft/gnutls/share/aclocal"
| |
− | | |
− | I put all of those commands into a file called <tt>devrc</tt> and then source it into my shell:
| |
− | . devrc
| |
− | <tt>$OLDPATH</tt> is there so that you can reset the path easily:
| |
− | export PATH=$OLDPATH
| |
− | | |
− | The other piece of the puzzle is that you need to specify some environment to configure. Paste the following into a file (in your top-level source directory) -- I call mine <tt>.configure</tt>:
| |
− | ./configure \
| |
− | --prefix=/c/soft/gnucash-inst \
| |
− | --enable-aqbanking \
| |
− | --enable-ofx \
| |
− | --enable-debug \
| |
− | --enable-schemas-install=no \
| |
− | --enable-dbi \
| |
− | --with-dbi-dbd-dir=/c/soft/libdbi-drivers/lib/dbd \
| |
− | --enable-binreloc \
| |
− | --enable-locale-specific-tax \
| |
− | CPPFLAGS="$CPPFLAGS -I/c/soft/autotools/include -I/c/soft/regex/include -I/c/soft/gnome/include -I/c/soft/guile/include -I/c/soft/libdbi/include -I/c/soft/gmp/include -I/c/soft/gwenhywfar/include -I/c/soft/libsoup/include -D_WIN32 -ggdb3 -Wall -Werror -fno-builtin-dgettext -fno-builtin-towupper -fno-builtin-iswlower" \
| |
− | LDFLAGS="$LDFLAGS -L/c/soft/autotools/lib -L/c/soft/regex/lib -L/c/soft/gnome/lib -L/c/soft/guile/lib -L/c/soft/libdbi/lib -L/c/soft/gmp/lib -L/c/soft/gwenhywfar/lib -L/c/soft/libsoup/lib -L/c/soft/enchant/lib -L/c/soft/libxslt/lib -L/c/soft/sqlite3/lib" \
| |
− | PKG_CONFIG_PATH=/c/soft/autotools/lib/pkgconfig:/c/soft/regex/lib/pkgconfig:/c/soft/gnome/lib/pkgconfig:/c/soft/guile/lib/pkgconfig:/c/soft/libdbi/lib/pkgconfig:/c/soft/gmp/lib/pkgconfig:/c/soft/gwenhywfar/lib/pkgconfig:/c/soft/libsoup/lib/pkgconfig:/c/soft/aqbanking/lib/pkgconfig:/c/soft/libofx/lib/pkgconfig:/c/soft/isocodes/lib/pkgconfig:/c/soft/libonoboui/lib/pkgconfig:/c/soft/libgsf/lib/pkgconfig:/c/soft/libxslt/lib/pkgconfig:/c/soft/webkit/lib/pkgconfig:/c/soft/enchant/lib/pkgconfig:/c/soft/gnutls/lib/pkgconfig:/c/soft/goffice/lib/pkgconfig
| |
− | | |
− | Then you call <tt>.configure</tt> instead of <tt>configure</tt> before you run <tt>make</tt>
| |
− | | |
− | == Update February 2014 ==
| |
− | When I went to try the above January 2014 instructions, I found that the code base for 2.6 has slightly advanced beyond the above instructions (post 2.6.1, ebdc4f8). These are my notes, which are in no way, shape, or form intended to be comprehensive but hopefully will save the next person a bit of time.
| |
− | | |
− | 1. First, several hunks of the patches didn't apply correctly, and needed to be manually applied. These included the variables for GWENHYWFAR_URL, GWENHYWFAR_PATCH, KTOBLZCHECK_VERSION, AQBANKING_VERSION, and AQBANKING_URL in src/packaging/win32/defaults.sh and lines in src/packaging/win32/install-imp.sh to apply the patch. All were fairly straightforward to plug into their source files after opening up the corresponding rejected file. The install-imp.sh changes to CPPFLAGS and LDFLAGS seemed unnecessary, and I didn't apply those rejected patches.
| |
− | | |
− | 2. The above instructions presume that active-perl installs in soft/active-perl/ActivePerl with a perl/bin subdirectory. That wasn't the case for me. I ended up installing Strawberry Perl 5.18.2 as a standalone. The PATH and INTLTOOL_PERL variables in devrc need to be updated to the correct path in this case.
| |
− | | |
− | 3. At one point, the .configure PKG_CONFIG_PATH needed a path to sqlite3. (It was installed, but isn't referenced in the package path.) However, my current .configure seems not to have it, and I'm not sure why it was needed at one point.
| |
− | | |
− | 4. Git automatically installed into git-1.7.10/bin/git for me, so the devrc GIT_CMD needed to be updated accordingly.
| |
− | | |
− | 5. Not mentioned above is that you can also do
| |
− | make install
| |
− | to get the Windows packaging effect without rerunning the install.sh script.
| |
− | | |
− | === Python Bindings ===
| |
− | What I wanted out of the above was Windows Python bindings. So rather than lament the lack of others doing the work, here's where I've gotten to so far.
| |
− | 1. To devrc, add
| |
− | export PYTHON=/c/Python27/python
| |
− | or where ever your python is. Note that this needs to be a 32-bit version of Python or things will go weird later on. I have not yet figured how to build 64-bit.
| |
− | | |
− | 2. I ended up setting all of these Python variables in .configure:
| |
− | PYTHON_SITE_PKG="/c/Python27/Lib/site-packages" \
| |
− | PYTHON_EXTRA_LIBS="-lpython27" \
| |
− | PYTHON_LDFLAGS="-L/c/Python27/libs" \
| |
− | PYTHON_EXTRA_LDFLAGS=" " \
| |
− | PYTHON_CPPFLAGS="-I/c/Python27/include " \
| |
− | The extra ldflags and extra libs were necessary to keep it from using the string 'None' when they were blank. This is likely a build bug. Note that again, this needs be the 32-bit version of Python (unless you are building 64-bit).
| |
− | | |
− | 3. I added
| |
− | -L/c/Python27/libs -lpython27
| |
− | to the LDFLAGS variable. I realize this duplicates PYTHON_LDFLAGS and PYTHON_EXTRA_LIBS, but configure won't pass without the LDFLAGS change. I suspect that the two PYTHON variables could be set to spaces (not empty because then they revert to 'None' which fails), but with the long build times, I have not tried it.
| |
− | | |
− | 4. To the configure options in .configure, I added
| |
− | --enable-python \
| |
− | | |
− | 5. I removed the -Werror from CPPFlags. There are some redefine problems regarding HAVE_PUTENV between the python headers and the config header. Rather than solve it, I simply allowed warnings.
| |
− | | |
− | 6. If desired, update the configuration in src/packaging/win32/install-impl.sh inst_gnucash() function (around line 1211) to include the above updates. This should let install.sh mostly work.
| |
− | | |
− | 7. Unfortunately, there is a path problem with the installation of src/optional/python-bindings where it uses Windows style path separators. My solution was to
| |
− | ./.configure
| |
− | make
| |
− | Edit src/optional/python-bindings/Makefile and replace the existing pyexecdir and pythondir with
| |
− | pyexecdir = ${exec_prefix}/Lib/site-packages
| |
− | pythondir = ${prefix}/Lib/site-packages
| |
− | And then resume with
| |
− | make install
| |
− | | |
− | 8. The result should be a gnucash-inst/lib/site-packages/gnucash directory with several python files and a .dll. Unfortunately, python won't load the dll, so it needs to be copied to _gnucash_core_c.pyd.
| |
− | | |
− | 9. This is as far as I have gotten. With a 32-bit version of Python, I can import gnucash, but it won't load because of missing dependency modules. I'm still working on tracking down the right approach to solve this.
| |
− | | |
− | = Alternative way to develop on a Windows machine =
| |
− | | |
− | You may also prefer to work on GnuCash in its native environment. An alternative approach to developing GnuCash on Windows could be to
| |
− | | |
− | * download a [http://en.wikipedia.org/wiki/Linux_distribution Linux Distribution] of your choice and
| |
− | * use [http://en.wikipedia.org/wiki/Multi_boot Multi Boot] to switch between Windows and Linux or
| |
− | * run Linux in a [http://en.wikipedia.org/wiki/Virtual_machine Virtual Machine] and
| |
− | * develop under Linux.
| |
− | | |
− | = Notes =
| |
− | == Error messages, Trace file ==
| |
− | When running into problems when running GnuCash, the trace file is usually your first stop to look for errors. You will find more details on this file [[Windows#Error messages, Trace file|here (Windows specific)]] and [[Tracefile|here (More generic)]].
| |
− | | |
− | == Debugging with gdb ==
| |
− | In addition to [[Stack Trace]], here are a few instructions on how to run gnucash under gdb on Windows:
| |
− | * Install "gdb" from mingw.org [http://downloads.sourceforge.net/mingw/gdb-6.3-1.exe]
| |
− | * '''GnuCash 2.2.9 and older'''
| |
− | :* Modify the installed "bin\gnucash.cmd" script by inserting one and changing one line. It should end like
| |
− | set PATH=C:\Program Files\gdb\bin;%PATH%
| |
− | start gdb --args gnucash-bin %*
| |
− | ::Be careful to use the actual paths in which you have installed gdb.exe
| |
− | :* Then start gnucash as usual
| |
− | *'''GnuCash 2.4.0 and more recent'''
| |
− | :* Open a Windows command prompt and type:
| |
− | set PATH=C:\Program Files\gdb\bin;%PATH%
| |
− | gdb "C:\Program Files\gnucash\bin\gnucash"
| |
− | ::Be careful to use the actual paths in which you have installed gdb and gnucash respectively.
| |
− | *'''For all versions''': this will open a gdb prompt
| |
− | * Type <tt>run</tt> at the gdb prompt.
| |
− | * Then provoke the crash and type <tt>backtrace</tt> or shorthand <tt>bt</tt> at the gdb prompt to obtain the backtrace, as explained on [[Stack Trace]] as well.
| |
− | | |
− | ('''2.2.9 and older only''')If you are working in a MinGW shell, you may want to change and call the bin\gnucash script instead and use <tt>exec start gdb --args gnucash-bin "$@"</tt> to make <tt>Ctrl-C</tt> actually work.
| |
− | | |
− | If you build gnucash with the help of install.sh, make sure you export <tt>DISABLE_OPTIMIZATIONS=yes</tt> in <tt>packaging/win32/custom.sh</tt> to include debugging symbols and avoid optimizations that complicate debugging.
| |
− | | |
− | You can provide even better stack traces if you tell gdb where in memory dynamically loaded modules got mapped to, because otherwise function calls into those are only written as '??'. See [http://lists.gnucash.org/pipermail/gnucash-devel/2006-November/019042.html here] and [http://lists.gnucash.org/pipermail/gnucash-devel/2006-November/019048.html here] for a way to do this.
| |
− | | |
− | To enter <tt>[</tt> and <tt>]</tt>, use <tt>set editing off</tt>.
| |
− | | |
− | == install.sh ==
| |
− | * To debug install.sh, change <tt>set -e</tt> to <tt>set -ex</tt> at the top of it.
| |
− | | |
− | == Console output and exetype ==
| |
− | All executables and DLLs on Windows operate in one of a few different subsystems, most of them either in <tt>Console</tt> or <tt>GUI</tt> (also called <tt>Windows</tt>). Basically, executables in Console always start up in a new console window and print output for stdout und stderr to it, whereas ones in GUI do not open windows and are pretty quiet, even in console windows. If you want to change that subsystem type, because you want to see debugging output or hide unnecessary console windows, [http://lists.gnucash.org/pipermail/gnucash-user/2007-April/020151.html] lists a few possible ways.
| |
− | | |
− | The easiest option if you don't have any further build tools available is probably the third one from that mail: Install the MSYS program (needed for building GnuCash) from the pointer at the top section of this page, fetch http://svn.gnucash.org/trac/browser/gnucash/trunk/packaging/win32/exetype.pl
| |
− | and type
| |
− | exetype.pl gnucash-bin.exe console
| |
− | | |
− | If you are building gnucash with install.sh, you might want to automate this step. To do so, just add the following lines to the function make_install in your local install.sh (after "make install"):
| |
− | qpushd $_INSTALL_UDIR/bin
| |
− | exetype gnucash-bin.exe console
| |
− | qpopd
| |
− | | |
− | = Problems, issues, comments =
| |
− | After spending 3-4 hours with after creating 35,074 files I got an error like that:
| |
− | | |
− | 100%[======================================>] 3,509,072 59.9K/s in 33s
| |
− | | |
− | 2014-01-10 14:26:40 (104 KB/s) - `/c/soft/tmp/htmlhelp.exe' saved [3509072/35090
| |
− | 72]
| |
− | | |
− | !!! When asked for an installation path, specify c:\soft\hh !!!
| |
− | ./install-impl.sh: line 1244: /c/soft/downloads/htmlhelp.exe: Bad file number
| |
− | | |
− | | |
− | ==DLL install error==
| |
− | I get an error like that:
| |
− | | |
− | 'libgncmodule.la' 'c:/soft/gnucash/lib/libgncmodule.la'
| |
− | /bin/install -c .libs/libgncmodule.dll.a
| |
− | c:/soft/gnucash/lib/libgncmodule.dll.a
| |
− | base_file=`basename ${file}`
| |
− | dlpath=`/bin/sh 2>&1 -c '. .libs/'${base_file}'i;echo $dlname'`
| |
− | make[5]: *** [install-libLTLIBRARIES] Error 1
| |
− | make[5]: Leaving directory `/c/soft/repos/src/gnc-module'
| |
− | make[4]: *** [install-am] Error 2
| |
− | | |
− | This seems to be only an installation problem. Fine compiling it seems.
| |
− | :I saw this at "make install" when I stopped and restarted the preceding compiling several times. So to me this looks like an artifact of DLLs that somehow "don't fit" to each other. The solution was always to run "make clean" in the source directory so that all DLLs are being deleted, and then starting the compiling again. --[[User:Cstim|Cstim]] 05:55, 4 December 2006 (EST)
| |
− | | |
− | I still see this error frequently, even when I completely remove the build/ directory and let it be created from scratch. (?!?) As an alternative, I've now tried a newer libtool version by installing the cvs snapshot libtool-1.5.23a from http://www.gnu.org/software/libtool/ . Maybe the newer version has this bug fixed. --[[User:Cstim|Cstim]] 10:27, 22 January 2007 (EST)
| |
− | :Seems like using libtool-1.5.23a didn't change a thing. I've written a script that should track down potential errors:
| |
− | | |
− | <pre> | |
− | #!/bin/sh
| |
− | ALL_LIBDIR=` find . -name '*.la' | grep '\.libs' `
| |
− | RM_THESE=""
| |
− | | |
− | for LIB in $ALL_LIBDIR ; do
| |
− | DIR=`dirname ${LIB}`
| |
− | FNAME=`basename ${LIB}`
| |
− | LIBBASE=`basename ${LIB} .la`
| |
− | if test ! -f "${LIB}i" -a -f "${DIR}/${LIBBASE}.dll.a" ; then
| |
− | echo "File ${LIB}i missing"
| |
− | PDIR=`dirname ${DIR}`
| |
− | #echo "Do this: rm ${PDIR}/${FNAME}"
| |
− | RM_THESE="${RM_THESE} ${PDIR}/${FNAME}"
| |
− | fi
| |
− | done
| |
− | | |
− | if test "x${RM_THESE}" != "x"; then
| |
− | echo "Do this:"
| |
− | echo "rm ${RM_THESE}"
| |
− | fi
| |
− | </pre>
| |
− | | |
− | So how is someone supposed to use the above script? It says it is supposed to track down potential errors, since it is doing some erasing (rm) does that mean it is fixing the problems as well? Or at least fixing it such that running install.sh again should work?
| |
− | | |
− | I have now run <tt>make clean && make all install</tt> in a particular directory 3 times but still get the same error.
| |
− | | |
− | == Missing file after extracting Open SSL on Windows XP Pro ==
| |
− | | |
− | '''Note''' I have never run into this issue since I started to work with the Windows build (somewhere in the 2.3.x period). So it may no longer be relevant. There is however no date or version information in the message, so I'll keep it around for now. It may move to the History section at some point.
| |
− | --[[User:GJanssens|GJanssens]] 18 October 2013
| |
− | | |
− | This is the error that I got:
| |
− | | |
− | 3200K .......... .......... .......... .......... .......... 99% 145.77 KB/s
| |
− | 3250K .......... ... 100% 834.05 KB/s
| |
− | <br>
| |
− | 20:36:43 (145.65 KB/s) - `c:/soft/tmp/openssl-0.9.8e.tar.gz' saved [3341665/3341665]
| |
− | <br>
| |
− | Extracting openssl-0.9.8e.tar.gz ... done
| |
− | The system cannot find the path specified.
| |
− | | |
− | This is the first error that I got. Everything was fine up to this point.
| |
− | | |
− | When I turn on <tt>set -ex</tt>, I get the following:
| |
− | | |
− | ++ cp e_os.h e_os2.h include/openssl
| |
− | +++ unix_path 'C:\WINDOWS\system32\cmd.exe'
| |
− | +++ echo 'C:\WINDOWS\system32\cmd.exe'
| |
− | +++ sed 's,^\([A-Za-z]\):,/\1,;s,\\,/,g'
| |
− | ++ _COMSPEC_U=/C/WINDOWS/system32/cmd.exe
| |
− | ++ PATH=/c/soft/active-perl/ActivePerl/Perl/bin:/c/soft/mingw/bin
| |
− | ++ /C/WINDOWS/system32/cmd.exe //c 'ms\mingw32'
| |
− | The system cannot find the path specified.
| |
− | | |
− | :Does that mean that your system lacks <tt>C:\Windows\System32\cmd.exe</tt>, <tt>$TMP_DIR\openssl-0.9.8e\ms\mingw32.bat</tt> or what do you think?
| |
− | | |
− | <tt>C:\Windows\System32\cmd.exe</tt> is definitely there.<br>
| |
− | So is <tt>C:\soft\tmp\openssl-0.9.8e\ms\mingw32.bat</tt>.
| |
− | | |
− | If I hardcode the full path to <tt>mingw32</tt> in <tt>install.sh</tt> like this:
| |
− | | |
− | PATH=$_ACTIVE_PERL_UDIR/ActivePerl/Perl/bin:$_MINGW_UDIR/bin $_COMSPEC_U //c <b>c:\\soft\\tmp\\openssl-0.9.8e\\</b>ms\\mingw32
| |
− | | |
− | <tt>ming32.bat</tt> starts to execute but it generates its own set of errors:
| |
− | | |
− | > perl Configure mingw
| |
− | Can't open perl script "Configure": No such file or directory
| |
− | Generating x86 for GNU assember
| |
− | Bignum
| |
− | The system cannot find the path specified.
| |
− | Can't open perl script "bn-586.pl": No such file or directory
| |
− | Can't open perl script "co-586.pl": No such file or directory
| |
− | DES . . .
| |
− | | |
− | So to get beyond that problem, I modified mingw32.bat to start out with a <tt>cd</tt> command, since it was starting in the <tt>C:\</tt> directory:
| |
− | | |
− | <b>cd C:\soft\tmp\openssl-0.9.8e</b>
| |
− | perl Configure mingw %1 %2 %3 %4 %5 %6 %7 %8
| |
− | @echo off
| |
− | | |
− | which allowed it to run a bit further and generated this error:
| |
− | | |
− | Generating x86 for GNU assember
| |
− | Bignum
| |
− | DES
| |
− | crypt
| |
− | Blowfish
| |
− | CAST5
| |
− | RC4
| |
− | MD5
| |
− | SHA1
| |
− | RIPEMD160
| |
− | RC5\32
| |
− | CPUID
| |
− | Generating makefile
| |
− | Generating DLL definition files
| |
− | Building the libraries
| |
− | Building OpenSSL
| |
− | mingw32-make: *** [banner] Error 1
| |
− | | |
− | I don't think I should keep making these minor adjustments to install.sh and mingw32.bat. There must be something I've done wrong that is causing this problem to appear in the first place.
| |
− | | |
− | --[[User:FELap09|FELap09]]
| |
− | | |
− | : I am sorry, I do not really know how to help you other than "delete c:\soft\tmp\openssl-*, c:\soft\openssl and retry with -ex". -- [[User:Andi5|andi5]]
| |
− | | |
− | : I had a similar problem compiling OpenSSL. It was fixed by uninstalling mingw from its custom location, then allowing the install.sh script to reinstall it. -- [[User:Cedayiv|cedayiv]]
| |
− | | |
− | == Logitech QuickCam conflicts ==
| |
− | | |
− | Some Logitech QuickCam software is incompatible with MSYS, and causes the install.sh script to randomly crash and create sh.exe.stackdump files. If you experience this problem, see the [http://www.mingw.org/wiki/FAQ MSYS FAQ page] or the [http://readlist.com/lists/lists.sourceforge.net/mingw-msys/0/341.html MinGW mailing list] for help.
| |
− | | |
− | | |
− | = Older information, mainly for reference =
| |
− | == Guile 1.8 ==
| |
− | The following is obsolete: The build scripts for 2.4 and trunk correctly build Guile 1.8. The notes are retained for historical interest.
| |
− | | |
− | GnuCash/Windows currently uses guile 1.6.x. Guile's development continues and the use of this old, no longer supported version of guile is blocking some improvements. Recent examples of this were:
| |
− | * Guile 1.8.7 removed some deprecated functions. However, the replacement functions were not available in 1.6.x. Because of this, GnuCash has to carry a compatibility header. We were lucky to get away with that.
| |
− | * Andy Wingo provided patches to make GnuCash work with the upcoming guile 2.0 and to remove our dependency on slib. These patches are incompatible with guile 1.6.x (and likely will always be), so they couldn't all be applied.
| |
− | | |
− | I have been attempting for some time to build a more recent version of guile but this turns out to be rather difficult. At the time of this writing, I have a working guile, save it won't load slib. There were many small things I had to do to get to this point. In order not to forget them, I've chosen to document them here.
| |
− | | |
− | === Getting it to build ===
| |
− | The 1.8.7 tarball you can download from guile's homepage won't build in our GnuCash mingw/MSYS environment.
| |
− | | |
− | * First error is that our version of automake is too old. Guile requires 1.11, GnuCash still builds with 1.10 at the time of this writing. Luckily, this can easily be fixed by updating the version in defaults.sh and rebuilding the autotools/libtool packages.
| |
− | * Guile 1.8.7 no longer contains its own libltdl implementation. This is provided with libtool though. All it required to fix this was to add the proper paths to CPPFLAGS and LDFLAGS.
| |
− | * Also new is that guile now requires gmp. Another addition to CPPFLAGS and LDFLAGS solves this.
| |
− | * Next is libintl. GnuCash builds this as part of the Gnome packages. However, we pull in the gnome libraries '''after''' we build guile. This doesn't work. So the build script has to be modified to first do the gnome install and then build guile.
| |
− | * Guile 1.8.7 still recognizes the configure time option --disable-networking, yet it won't build on Windows if this option is set. So this option should be '''removed''' from the build script.
| |
− | * Next, all kinds of unresolved symbol errors pop up. To fix most of them, I looked at the source package of MSYS-guile-1.8.7. They apparently managed to build guile, so it provided a good starting point. I can't use their patches verbatim, because that would result in a guile package that depends on the MSYS environment. Their patch for config.in was very useful though. To build build with this patch, the configure script has to be rebuilt, using autoreconf. This in itself was a bit of a quest. It wouldn't work unless I redefined ACLOCAL and passed autoreconf a number of library paths.
| |
− | * I also learned from the MSYS-guile project that guile should be built with "-Wl,enable-auto-import" to avoid a number of linker warnings (which are treated as errors in our build process).
| |
− | | |
− | That was about all to get the library and executable to build. But then it really gets ugly. The next part of the guile build process uses the freshly compiled executable to setup other required bits. This fails miserably with a rather cryptic error <pre>ERROR: In procedure scm_i_lreadparen: #<unknown port>:1:7: end of file</pre>.
| |
− | | |
− | It took me quite a while to grasp this one. I found several threads on different mailing lists about the error, which where more or less helpful:
| |
− | * http://www.mail-archive.com/bug-guile@gnu.org/msg04711.html, which at some point links to http://lists-archives.org/mingw-users/14268-problem-with-argc-argv-under-msys.html, which in turn refers to http://thread.gmane.org/gmane.comp.gnu.mingw.msys/3719. The solution mentioned here, didn't apply in my case, but I got to understand the problem a little better.
| |
− | * Then I was lucky enough to stumble upon two thread in the mingw-devel list: [http://lists.gnu.org/archive/html/guile-devel/2009-03/msg00098.html Again on windows support] and [http://lists.gnu.org/archive/html/guile-devel/2009-06/msg00193.html Again on windows support (2)]. These are two long threads on building guile on windows and the issues in it. I learned here that the build process uses a wrapper program around the guile executable. Confusingly, this wrapper is called guile.exe as well, yet it has issues on windows, that the actual guile.exe doesn't have. So I wrote a small patch to use that actual guile.exe instead of the wrapper during the build process.
| |
− | | |
− | '''Result''': the guile build process completes, and the guile binary works - provided it can find all of its library dependencies of course.
| |
− | <pre>guile -c '(use-modules (srfi srfi-39))'</pre> runs with no problems.
| |
− | | |
− | === slib ===
| |
− | | |
− | This is still problematic at this point.
| |
− | <pre>guile -c "(use-modules (ice-9 slib)) (require 'printf)"</pre> results in this error:
| |
− | ERROR: In procedure open-file:
| |
− | ERROR: No such file or directory: "C:/GCDevel/guile/share/guile/1.8/slib/C:/GCDevel/guile/share/guile/1.8/slib/require"
| |
− | ABORT: (system error)</pre>
| |
− | | |
− | Obviously there's something wrong with the path guile uses to find the file require.scm.
| |
− | | |
− | I'm still investigating what happens here.
| |
Development on Microsoft Windows isn't really encouraged. The build environment isn't really conducive to development and many of the unit tests don't work. However, if you must...
The build system for GnuCash 2.7 and later supports Windows 7 and later. The procedure is a bit simpler than for GnuCash 2.6 and earlier and provides a somewhat easier to use development environment. That doesn't mean that we recommend that you use Windows for development: GnuCash is very much a Unix program and development is much easier in a Unix environment like Linux, BSD, or MacOS.
The build system relies heavily on Windows PowerShell.
Depending on your security settings you may need to enable running scripts on your computer. For this open a powershell with Administrator privilages and run:
. Depending on where you want to put the development tree you may need to run PowerShell as an administrator. Once you've downloaded the script start PowerShell. You can review the script's parameters with
Next open the Start menu and navigate to MSYS2 64Bit or MSYS2 32Bit; which you want will depend upon the bitness of your Windows version. If you specified x86_64 $true to setup-mingw64.ps1 you'll want to start the mingw64 shell, otherwise the mingw32 shell.
In that shell window navigate to the gnucash-on-windows.git directory in the target directory to specified to setup-mingw64.ps1. We'll use the default for the following examples.
One of the things setup-mingw64.ps1 did was checkout the rest of the gnucash-on-windows repository in target_dir/src/gnucash-on-windows.git. That contains a customization (python) script and a jhbuild moduleset. The customization script selects one of the three GnuCash branches to build based on the value of $TARGET; the possibilities are gnucash-stable (the default), gnucash-unstable (the unstable release git branch) and gnucash-releases, which builds GnuCash from the tarball specified in gnucash.modules instead of from a git branch.The first time jhbuild build command will build GnuCash, GnuCash Docs, and all of the dependencies that Mingw-w64 doesn't provide. After that it only builds modules that need rebuilding unless you tell it otherwise; see the jhbuild manual for details on controlling jhbuild.
You can start a subshell with the paths to hand-compile or run GnuCash from the command line with
This is convenient for development as one can navigate to the gnucash build directory and re-run CMake and make as necessary while developing.
Be sure to use a programming editor that preserves line ending style; git can get really unhappy if you put the wrong kind of line endings into a file.
To build a package for installation there's a PowerShell script called
suitable for use with the Task Scheduler for periodic builds. Each includes documentation accessible with PowerShell's
command, e.g.
GDB can be used on windows without too much effort. Usually it's better to attach to an already running process instead of trying to launch directly under GDB. Ctrl+C does not work as well under GDB, however this site has a workaround: Workaround for GDB Ctrl C Interrupt
Microsoft's Visual Studio Code is a possibility to integrate with gnucash and gdb for debugging. The following launch.json file can be used to debug with gdb under vscode:
to build the program.
will set the necessary environment variables so that you can re-run the build script as usual in gnucash/build
and run GnuCash from gnucash/inst/bin