Compile Guncash

Mon Mar 30 11:19:16 EDT 2015

On 03/30/2015 07:37 AM, Geert Janssens wrote:
> On Saturday 28 March 2015 15:14:24 Tommy Trussell wrote:
>> On Sat, Mar 28, 2015 at 1:19 PM, AC <gnucash at acarver.net> wrote:
>>> On 2015-03-28 00:14, Geert Janssens wrote:
>>>> On Friday 27 March 2015 15:28:27 AC wrote:
>>>>> On 2015-03-27 15:06, Colin Law wrote:
>>>>>> On 27 March 2015 at 18:18, AC <gnucash at acarver.net> wrote:
>>>>>>> On 2015-03-27 09:25, Dennis Powless wrote:
>>>>>>>> I had read the readme file and was not very helpful.
>>>>>>>>
>>>>>>>> I had entered the command.   ./configure but got errors.  I
>>>>>>>> want
>>>>>>>> to say it was the target, but later when I had stated the
>>>>>>>> target
>>>>>>>> it worked.
>>>>>>>>
>>>>>>>> Why does the above mentioned wiki have me make a .deb file,
>>>>>>>> when
>>>>>>>> others don't.  This didn't work.
>>>>>>>>
>>>>>>>> Checkinstall vs make install
>>>>>>>>
>>>>>>>> Thanks for the info,  very helpful
>>>>>>>
>>>>>>> I don't understand why the tarball insists on making a .deb (or
>>>>>>> if
>>>>>>> the wiki is confused and suggests it makes one when the tarball
>>>>>>> really doesn't).  Most of the time when compiling from a
>>>>>>> tarball
>>>>>>> the binaries are made directly (no deb's) and installed
>>>>>>> directly.
>>>>>>> If the tarball really is making a deb then I suspect it's to
>>>>>>> ensure that gnucash shows up in the package manager.
>>>>>>
>>>>>> The tarball does not insist on making a deb, it is just that the
>>>>>> person that wrote that section of the wiki wanted to do it that
>>>>>> way.
>>>>>> When I did the entries for earlier versions of Ubuntu (which can
>>>>>> be
>>>>>> seen in the wiki) I just compiled to binaries and ran or
>>>>>> installed
>>>>>> from those.  If I needed to compile gnucash now I would do it
>>>>>> the
>>>>>> way
>>>>>> I described rather than making a deb, which I think just adds
>>>>>> complexity.  Also I think it is better to get the source from
>>>>>> git
>>>>>> rather than using the tarball.
>>>>>
>>>>> Ok, perhaps that section should end up being split into a
>>>>> standard
>>>>> compile with direct binaries and then the optional deb later.  It
>>>>> seems to cause enough confusion especially when the instructions
>>>>> are
>>>>> different from the portions you wrote.
>>>>
>>>> Good suggestion. Feel free to go in and improve this. As this is a
>>>> wiki everybody is encouraged to work on it.
>>>
>>> I'll take a look but I don't use Ubuntu so I can't really edit that
>>> particular section.  It just has too many idiosyncrasies.  Best I
>>> could do would be to add a generic section.
>>
>> I don't believe Ubuntu necessarily has more idiosyncrasies than any
>> other distro;
> To be honest I see more Ubuntu specific bug reports than for any other
> distro. I never bothered searching for the cause, so this can both be
> that more people try to self-build gnucash on that platform than on
> others, or that Unity sometimes steps on gtk's toes in subtle ways.
>
>> folks have merely used the Ubuntu section to try out
>> lots of different things, and presented them as if they are Ubuntu
>> version dependent. In practice, the only things that SHOULD vary with
>> Ubuntu releases are the versions of particular supporting libraries
>> and maybe a few tweaks based on those.
>>
> That's certainly true.
>
>> I have been puzzling over this for awhile -- there are lots of options
>> that really ought to be described better in the wiki:
>>
>> 1) DEB: whether or not to create a .deb package (applies to Debian or
>> Ubuntu) -- the advantage to a .deb is you can compile the package to
>> install in any standard or non-standard location and remove it easily
>> using the package manager. (Surely there might be a similar procedure
>> for building your own .rpm but I don't use Fedora etc. daily and
>> haven't looked.)
>>
> While a .deb/.rpm package is indeed useful as it allows your custom
> built gnucash to be managed by your distro's package manager, it's
> optional. And the wiki probably should explain that.
>
> Note that to get to a .deb/.rpm package the same build steps as a manual
> build are used as well, only now it's the package build system that runs
> those so it's not obvious for the user. And this package build system
> takes slightly different inputs as for a manual build. So it really
> should be a separate section.
>
>> 2) SOURCE: how you downloaded the source (git, tarball, or Debian /
>> Ubuntu source packages) -- as Geert happened to bring up recently in
>> the -devel list, the compilation procedure differs depending upon
>> where the source came from.
> That's true, although for the one initiating the build there's only one
> single difference:
> - when starting from git, the first command to run is ./autogen.sh in
> the source directory
> - when starting from a (release) tarball, this command can be omitted.
>
> There are a few more differences but these are internally handled by the
> build scripts automatically.
>
>> (I personally tried to wrangle the
>> section about
>> "self-backporting" using the Debian or Ubuntu source packages but I
>> wasn't able to make that work reliably in recent versions. This is
>> certainly due to my ignorance, though, because the source packages
>> obviously compile correctly for Debian and Ubuntu and GetDeb
>> builders.)
>>
> Not necessarily. Packagers often add custom patches to their builds in
> order to make them succeed. Most packagers also report these to the
> gnucash community so we can include them in our sources as well, but
> that doesn't always happen.
>
>> 3) INSTALLATION LOCATION: where GnuCash executables get installed (the
>> standard Debian / Ubuntu location, or a local single-user-only
>> location, or a traditional linux site-local installation, or ... )
>>
>> 4) COMPILE OPTIONS: what compile-time options are absolutely necessary
>> or just recommended, and a brief description of what they do.
>>
>> 5) other common choices not reflected above?
>>
>> 6) VERSION-SPECIFIC: the sections that vary based on your version of
>> Ubuntu or Debian (or whatever) should be separate choices. HOWEVER
>> folks want to be able to jump right in and compile away without
>> thinking about options 1-5.
>>
>>
>> What's the best way to present all these things? Is there any way to
>> show them in the wiki that would be maintainable? Most of these
>> choices are not even specific to Ubuntu.
> I agree that building gnucash is 90% the same steps and commands on most
> (linux) distros. So I would recommend first writing a page with general
> build instructions. And that page should go into more detail on each of
> the topics you mention above.
>
> And then based on that one could make distro specific recommendations,
> like how to get the necessary build dependencies installed, or how to
> build a .dep/.rpm package, or how to deal with some very distro-specific
> oddity. These distro specific pages should refer to the base build page
> for everything that doesn't deviate.
>
> Does that make sense to you ?

Here's a trick. Go and look at one of the source code based linux 
distros to see how the building of the gnucash codes are automated.
Arch and Gentoo linux are excellent examples. I use gentoo:

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-office/gnucash/

Gentoo also put the extensive docs into a separate package:

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-doc/gnucash-docs/

The gentoo devmanual is here (explaining the terms and macros):

https://devmanual.gentoo.org/

These ebuilds are read like pseudo code, so they are easy to comprehend
here is the 2.6.5 ebuild for gnucash:

cat gnucash-2.6.5.ebuild
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: 
/var/cvsroot/gentoo-x86/app-office/gnucash/gnucash-2.6.5.ebuild,v 1.3 
2015/03/15 13:15:45 pacho Exp $

EAPI="5"
GCONF_DEBUG="no"
PYTHON_COMPAT=( python{2_6,2_7} )

inherit autotools eutils gnome2 python-single-r1

DESCRIPTION="A personal finance manager"
HOMEPAGE="http://www.gnucash.org/"
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"

SLOT="0"
LICENSE="GPL-2"
KEYWORDS="amd64 ~ppc ~ppc64 x86"
IUSE="chipcard debug +doc hbci mysql ofx postgres python quotes sqlite"

# FIXME: rdepend on dev-libs/qof when upstream fix their mess (see 
configure.ac)
# libdbi version requirement for sqlite taken from bug #455134
RDEPEND="
	>=app-crypt/libsecret-0.18
	>=dev-libs/glib-2.32.0:2
	>=dev-libs/popt-1.5
	>=dev-libs/libxml2-2.5.10:2
	dev-libs/libxslt
	>=dev-scheme/guile-1.8.3:12[deprecated,regex]
	dev-scheme/guile-www
	gnome-base/libgnomecanvas
	>=net-libs/webkit-gtk-1.2:2
	>=sys-libs/zlib-1.1.4
	>=x11-libs/gtk+-2.24:2
	>=x11-libs/goffice-0.7.0:0.8[gnome]
	x11-libs/pango
	ofx? ( >=dev-libs/libofx-0.9.1 )
	hbci? ( >=net-libs/aqbanking-5[gtk,ofx?]
		sys-libs/gwenhywfar[gtk]
		chipcard? ( sys-libs/libchipcard )
	)
	python? ( ${PYTHON_DEPS} )
	quotes? ( dev-perl/DateManip
		>=dev-perl/Finance-Quote-1.11
		dev-perl/HTML-TableExtract )
	sqlite? ( >=dev-db/libdbi-0.9.0
		>=dev-db/libdbi-drivers-0.9.0[sqlite] )
	postgres? ( dev-db/libdbi dev-db/libdbi-drivers[postgres] )
	mysql? ( dev-db/libdbi dev-db/libdbi-drivers[mysql] )
"
DEPEND="${RDEPEND}
	>=app-text/scrollkeeper-0.3
	virtual/pkgconfig
	dev-util/intltool
	gnome-base/gnome-common
	sys-devel/libtool
"

PDEPEND="doc? ( >=app-doc/gnucash-docs-2.2.0 )"

pkg_setup() {
	use python && python-single-r1_pkg_setup
}

src_prepare() {
	# Skip test that needs some locales to be present
	sed -i -e '/test_suite_gnc_date/d' src/libqof/qof/test/test-qof.c || die

	eautoreconf
	gnome2_src_prepare
}
src_configure() {
	local myconf

	DOCS="doc/README.OFX doc/README.HBCI"

	if use sqlite || use mysql || use postgres ; then
		myconf+=" --enable-dbi"
	else
		myconf+=" --disable-dbi"
	fi

	# guile wrongly exports LDFLAGS as LIBS which breaks modules
	# Filter until a better ebuild is available, bug #202205
	local GUILE_LIBS=""
	local lib
	for lib in $(guile-config link); do
		if [ "${lib#-Wl}" = "$lib" ]; then
			GUILE_LIBS="$GUILE_LIBS $lib"
		fi
	done

	# gtkmm is experimental and shouldn't be enabled, upstream bug #684166
	gnome2_src_configure \
		$(use_enable debug) \
		$(use_enable ofx) \
		$(use_enable hbci aqbanking) \
		$(use_enable python) \
		--disable-doxygen \
		--disable-gtkmm \
		--enable-locale-specific-tax \
		--disable-error-on-warning \
		 GUILE_LIBS="${GUILE_LIBS}" ${myconf}
}

src_test() {
	unset DBUS_SESSION_BUS_ADDRESS
	GUILE_WARN_DEPRECATED=no \
	GNC_DOT_DIR="${T}"/.gnucash \
	emake check
}

src_install() {
	# Parallel installation fails from time to time, bug #359123
	MAKEOPTS="${MAKEOPTS} -j1" gnome2_src_install 
GNC_DOC_INSTALL_DIR=/usr/share/doc/${PF}

	rm -rf 
"${ED}"/usr/share/doc/${PF}/{examples/,COPYING,INSTALL,*win32-bin.txt,projects.html}
	mv "${ED}"/usr/share/doc/${PF} "${T}"/cantuseprepalldocs || die
	dodoc "${T}"/cantuseprepalldocs/*
}

Pretty simple shell and shelex syntax....
Many folks work on gentoo on a very wide variety of codes, then port to
the target platform. It's a coder's dream for a distro; lots of main 
devs among many well recognized projects around the world use Gentoo
to prototype, document and port, including a wide variety of embedded 
systems and archtectures.

hth,
James

hth,
James