OS orientated development

[Geert Janssens]

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.

I found some non-authoritative statistics, like for example a package 
statistics page for arch linux:
https://www.archlinux.de/?page=PackageStatistics
The way I interpret these stats, GnuCash is installed on for 7% of all 
Arch Linux installations.
Ubuntu also has some package statistics:
http://popcon.ubuntu.com/universe/gnome/by_inst
Almost 100.000 people who enabled the statistics gathering (not enabled 
by default) in Ubuntu installed GnuCash (gnucash-common).

> 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 
we require.
>
> 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.
>
> Surely
> 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 
coding effort.

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.

Geert