On 03-05-12 11:49, Wm Tarr wrote:
> While reading a recent thread here (the one on libgtk dependency) I
> wondered which OS gnc ended up on most.
> Looking at
> http://sourceforge.net/projects/gnucash/files/gnucash%20%28stable%29/stats/os?dates=2012-02-06%20to%202012-05-03 >
> (i.e. 2.4.10 stable until today) it appears to be Windows.
> I tried a number of other time periods but Windows seems to be the
> main OS regardless.
> I know there are other sources of gnc, for e.g. the one I use day to
> day comes from http://portableapps.com/ > Perhaps many more people use the gnc from their *nix distro? Do we
> have any stats for that? I'm guessing not.
I don't know of any statistics for GnuCash usage on *nix, but I'm pretty
sure the sourceforge stats will give a very distorted view of the
GnuCash usage. On sourceforge you will find binary installer packages
for Windows and OS X. For *nix, you will only find a source code
package. But other than a handfull of people experienced in building
applications from source code (distro packagers, developers,...) no one
will download that source package from source forge. Every distro
provides GnuCash nicely packaged from their own installation
repositories. So every ordinary user on *nix will install GnuCash from a
source *other* than sourceforge. And given GnuCash' roots in linux, I
would be *very* surprised if it were not used more on linux than on Windows.
> The thing I am thinking about is which version of the packages gnc
> depends on should be used?
> I am aware some might see this as "fighting talk", I am certainly not
> intending to start an OS war (there are plenty of other places for
> that! )
Good, because neither do I. I am in favour with having GnuCash on as
many platforms as possible.
> What I am wondering about is how much is gnc "held back" by the
> stability of (say) libgtk on one platform?
Why do you think GnuCash is "held back" by any library ? You refer to a
thread on libgtk, but you don't say exactly which thread. Did this
thread suggest that GnuCas was being "held back" ? Particularly libgtk
is actively maintained on Windows. We have seen bugs in it, that only
surfaced on Windows, but many of them got fixed in the mean time, others
have been worked around.
In general, I think GnuCash is on Windows is currently using up to date
libraries, many of them are even more recent than the minimal versions
> If this discussion has already been done to death then I would like a
> pointer to the thread.
> My aim (and that of some others) is a gnc with Python 2.7 (I can't see
> the need to leap to Python 3.x at the moment). The problem I (and
> possibly others) are finding is that the build involves sacrificing
> small animals, virgins and so on because it isn't clear which version
> of which package is required on which OS.
> http://code.gnucash.org/builds/win32/build-logs/build-trunk-2012-05-03.log >
> could include version numbers ... I'm prepared to write the sh code to
> show them if someone has a working combination. We shouldn't really
> have to do it by trial and error since we know someone (the person
> that compiles the Win32 version) knows which versions of which
> packages they are using.
All the required versions can be found in
src/packaging/win32/defaults.sh. This combination works for me and it
works on the build server. How are you trying to build GnuCash and what
problems are you having ?
> More generally, why, historically, is building gnc such a nightmare?
> Does it have to be that way?
I can understand your frustration. Building GnuCash on Windows is not
very user friendly. We do have a mostly automated script for this. It
works mostly ok, but can become confusing when problems arise. It
doesn't have to be this way, but as you say grew like this historically
and no one stepped in with a better solution so far.
> Consider this: if a Python 2.7 compatible Windows version was built
> you'd get a whole load of Python people writing new reports and so on,
> that would enhance rather than detract from gnc, surely?
That's a very optimistic view and - I hope you don't mind me saying so -
also slightly naive. There is no python reporting engine right now. The
current reporting engine is written in scheme (guile) and so are all the
reports. GnuCash does have some python bindings, but they are surely not
capable of replacing the current reporting engine without a serious
Mind you, I am not against that idea at all. If someone feels he can
write a reporting engine in python to replace the old scheme based one,
that would be great and certainly worth it. I only want to be clear that
just building GnuCash on Windows with python support is not enough to
suddenly have python reports and attracting lots of python developers to
the program. It's only one first necessary (and in my opinion relatively
small) step. The biggest part of the job is to make the GnuCash python
bindings attractive to report writers and keep everything coherent.
> Are their a bunch of jealous guys protecting their bit of the code?
> That sort of thing has happened with other open source projects
> before. I hope it is not true of gnc.
There is no one protecting its code. The state of the Windows build is
the result of a couple of facts.
1. GnuCash was originally written on linux for linux and other posix
compatible systems (think BSD and friends). This means the code is
heavily unix oriented. This shows in its library dependencies. The
Windows port was done much later. The port relies on mingw, which is a
set of libraries to provide some kind of linux compatible layer on top
of Windows. This means that GnuCash and the required libraries didn't
have to be changed much to work on Windows even though Windows and linux
have very different coding models. Mingw isn't perfect though and that
shows in GnuCash on Windows. Especially in parts where lower level code
is used, this can cause problems on Windows that don't show on linux.
2. Today's reality is that GnuCash doesn't have any developers that
actively use Windows themselves. The devs I know of are either on OS X
or linux. Most of the active developers do fix bugs in the Windows
build, but none of them is close enough with Windows to take on a
serious effort to improve the build system.
I'm happy you seem to be interested in in improved Windows build, so I
encourage you to make any improvements you see fit. I agree that there
is lots of room for improvement in the Windows build system. But first
it would be interesting to see which difficulties you have exactly.