GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[David T. via gnucash-devel]

Frank,

I am struggling right now to find the right way to bring up the issue of the 
Gnucash Draft Concept Guide, which still resides on the wiki.

As you know, I have proposed on numerous occasions (most recently, two and a 
half weeks ago) to have these pages removed from the wiki, since they are out 
of date, inaccurate, poorly written, superceded, and can turn up in search 
results, giving users incorrect information about Gnucash and its features and 
functions. 

In that recent thread, four people responded to my request to remove the Draft 
Concept Guide. Only you appeared to support retaining these pages, although 
your primary concern was with the mechanical aspects of Google’s search 
algorithm, upon which I have no expertise to comment. (I will note that fixing 
one search engine result set does not preclude some OTHER search engine now or 
in the future from finding and returning these pages despite your best 
intentions). 

You actually offered to move these pages to your own user area, but John noted 
that might not actually hide the results.

Two days ago, I went to the wiki to search for information about creating 
reconciliation reports in response to a question on the user list, and when I 
entered “reconciliation” into the wiki’s OWN search box, 4 of the first 5 hits 
were for the Draft Concept Guide.

Since there had been no support for your position to keep the pages, and since 
you had had two and a half weeks to take whatever action you had proposed to do 
(and not taken any), I felt it was time to address the Draft Concept Guide 
issue directly. 

I did not delete the pages outright (since I do not have the rights to do 
that), but I did what I considered to be the next best thing, which was to 
replace all the text in those pages with the latin nonsense that printers have 
used for hundreds of years to mock up page layouts (“Lorem ipsum”). I even made 
sure to retain the various structural elements in the pages, going so far as to 
replace headings and bullet points with latin phrases of similar length.

Since, as far as I understand, your only reason for retaining these pages is to 
serve as some sort of model for the Gnucash community to use for wiki pages, my 
technique allowed these model pages to be retained *without* their turning up 
in any search results, anywhere. So, that’s the best of both worlds, right?

Apparently not, as within hours, you had gone and reverted all my changes.

So, I have a few questions to ask of you, Frank, and of the community.

1) First, Frank: What exactly is so special to you about these pages? Why do 
you insist that they remain forever on the wiki? The only reason I have heard 
from you is this idea that the pages could provide wiki page template examples. 
But, my most recent changes preserved the template aspect without retaining the 
problematic language—and you still reverted the changes. So, there seems to be 
something *else* with these pages that makes you feel so protective. What is 
it? My recent changes seem to prove that there is something in the text itself 
that you are attached to. Can you explain clearly what that attachment is?

2) Frank, in the past, you have chastised me for reverting changes that you had 
made on wiki pages, and informed me that it is considered rude to do so. So, 
why are you so consistently rude to me? This is not the first time that you 
have reverted my changes.

3) To the community: Whose Wiki is this, anyway? I have presented to the 
community on separate occasions my reasons for wanting to remove these pages, 
and I have heard from most of the developer community that these pages could be 
removed. The only person opposed to this appears to be Frank. However, Frank’s 
wishes on this issue (and others regarding the Wiki) apparently take precedence 
over everyone else’s, such that if Frank doesn’t agree, then it won’t happen. 
That doesn’t sound much like a collaboration.

4) To the community: Again, I put the question to the group: what purpose and 
procedures are supposed to apply to the wiki? There appear to be numerous 
unwritten rules about how to engage with the process (see for example question 
2), and apparently I have broken those rules in this and other cases. It is 
frustrating to be encouraged to contribute to the wiki only to have those 
contributions rejected summarily. Establishing clear procedures and guidelines 
for contribution and workflow management seem to be in order—certainly if you 
expect non-developers to contribute back to the GnuCash community. 

Sincerely,
David T.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building (or trying to) GnuCash on Windows

[Brian Davis]

On Thu, Nov 30, 2017 at 3:46 PM, Geert Janssens 
wrote:

> It's time to move this thread to the gnucash-devel list. The discussion is
> evolving into the nitty gritty details of how gnucash is built. Not
> something
> most users will be interested in. If you reply please make sure to do so on
> the devel list.
>
>
ok so then to gnucash-devel list


>
> >
> > Why not use CMake to do all the heavy lifting?
> >
> Because no one implemented it that way, and CMake support is fairly recent
> in
> the gnucash build scripts.
>
>
Ok


> Besides the new build scripts leverage
> 1. prebuilt packages from mingw64 - no heavy lifting to be done any more
> 2.  jhbuild, which is quite capable of managing our dependencies that are
> not
> provided as prebuilt package by mingw64.
>
>
So to I start with jhbuild?


> > Scripts also install git... I have git... I also have CMake CMake can
> > use git command line tools... Why do I need git again?  CMake using
> > ExternalProject_Add can add gnucash.git, gnucash-on-windows.git.  Maybe
> it
> > could be changed from download-world-begin-build to
> > download-Texas-begin-build?
> >
> The goal of the bootstrap script was to lower the barrier to entry as much
> as
> possible, not to use as little disk space as possible. Before the bootstrap
> script people wanting to try building on Windows had to go through a list
> of
> packages to install and set up manually, tweaking configuration files in
> the
> process. This was even more cumbersome and error prone than what this
> simple
> bootstrap script achieves.
>

Yes my point exactly as with GTK.


>
> Still in a way I agree with you. The tools that are already available on
> the
> system shouldn't need to be installed again. Just shows the boostrap
> process
> can be improved.
>
> But even if you would manage to convert all of this setup stuff into cmake
> rules, I would expect some form of script or "sdk installer" to be
> available
> that would take care of getting cmake on the system in the first place. The
> core idea of the bootstrap script remains.


At one point I wrote a Windows Script Host to download the particular
version(s) of CMake to boot strap a full system.  Thankfully I came to my
senses and CMake now supports opening VS with environment variables
(environment) set by CMake 3.7+ or so.


> One single click should get the
> curious developer going. Not 20 manual downloads and 30 configuration
> tweaks
> (so to speak).
>

Amen brother.


> > What are deps on need for MSys/Mingw and could CMake take this over to
> > allow VS/MSbuild tools option?  Are there deps such as glib/GTK and other
> > dep friends where msbuild tools are not an option?
> >
> GnuCash is a glib/Gtk application, so yes those are primary deps. There are
> several others. For the stable series those are listed in defaults.sh, for
> the
> upcoming 2.8 series you will find them in gnucash.modules.
>
>
Ok


> I don't know whether CMake can take this all over. However the VS/MSbuild
> option doesn't depend on that IMO. The only part you should be concerned
> about
> is the gnucash code itself.


If only that were true.  It's one thing to say cross build on Linux, but
WHEN it fails on Windows... How do you go about attaching a debugger?


> All the deps can be considered as sdk, just set
> and forget. The gnucash code itself is already buildable via cmake, so the
> VS/
> Msbuild option is there to try. I'm pretty sure it will fail though as
> none of
> the current devs has ever tested it (we don't have any native Windows devs
> atm).
>


Yes the just download a dll or "windows binary" and get started method...
sigh.  But what about tracing bugs into those deps... see this is why I use
cmake to build my deps allowing me source level development of all 3rd
party goop. A glorious option.  Yes with some packages on the web this is
possible.  This does not look like an option with msys/mingw and GTK deps
however.


>
>
> 2.8 on the other hand switched to mingw64 and we leverage the packages they
> provide to a maximum to avoid having to rebuild everything ourselves. These
> packages are maintained via https://github.com/Alexpux/MINGW-packages on
> github. Packages not available there we build ourselves. For the 2.8 series
> this is managed via jhbuild. This allows us to reuse much of the work
> already
> done to build gnucash on OS X (which also uses jhbuild).
>
>
So how does one start with 2.8 then?  Say is there a website or something
that explains this?


> > There are GTK deps that do build well (are supported) by CMake such as
> if i
> > remember correctly Zlib, LibPNG, LIbjpeg or Jasper, LibTiff, freetype
> (has
> > CMakeLists.txt file), Expat, pcre2 etc.  Pixman(cairo dep) or dgk-pixbuf
> > not so much.  Though I have seen where eventhough there is a
> CMakeList.txt
> > file a project is not fully windows supported (MSBuild tools)  where
> there
> > are deps on build environment Cygwin or MSys.  Sometimes its "hey just
> 

Re: Building (or trying to) GnuCash on Windows

[Geert Janssens]

It's time to move this thread to the gnucash-devel list. The discussion is 
evolving into the nitty gritty details of how gnucash is built. Not something 
most users will be interested in. If you reply please make sure to do so on 
the devel list.

Op donderdag 30 november 2017 20:54:33 CET schreef Brian Davis:
> > Looking more closely at this, it turned out to be a bug in the boostrap
> > script. I have committed a fix for this just now. So if you start from the
> > most recent version of the script, it should work even when not explicitly
> > called from cscript.
> 
> In looking at the parts that did work it seemed to be installing a msys
> build environment.  There is also some reference to CMake.  Now the
> questions:
> 
> Why not use CMake to do all the heavy lifting?
> 
Because no one implemented it that way, and CMake support is fairly recent in 
the gnucash build scripts.

Besides the new build scripts leverage
1. prebuilt packages from mingw64 - no heavy lifting to be done any more
2.  jhbuild, which is quite capable of managing our dependencies that are not 
provided as prebuilt package by mingw64.

> Scripts also install git... I have git... I also have CMake CMake can
> use git command line tools... Why do I need git again?  CMake using
> ExternalProject_Add can add gnucash.git, gnucash-on-windows.git.  Maybe it
> could be changed from download-world-begin-build to
> download-Texas-begin-build?
> 
The goal of the bootstrap script was to lower the barrier to entry as much as 
possible, not to use as little disk space as possible. Before the bootstrap 
script people wanting to try building on Windows had to go through a list of 
packages to install and set up manually, tweaking configuration files in the 
process. This was even more cumbersome and error prone than what this simple 
bootstrap script achieves.

Still in a way I agree with you. The tools that are already available on the 
system shouldn't need to be installed again. Just shows the boostrap process 
can be improved.

But even if you would manage to convert all of this setup stuff into cmake 
rules, I would expect some form of script or "sdk installer" to be available 
that would take care of getting cmake on the system in the first place. The 
core idea of the bootstrap script remains. One single click should get the 
curious developer going. Not 20 manual downloads and 30 configuration tweaks 
(so to speak).

> What are deps on need for MSys/Mingw and could CMake take this over to
> allow VS/MSbuild tools option?  Are there deps such as glib/GTK and other
> dep friends where msbuild tools are not an option?
> 
GnuCash is a glib/Gtk application, so yes those are primary deps. There are 
several others. For the stable series those are listed in defaults.sh, for the 
upcoming 2.8 series you will find them in gnucash.modules.

I don't know whether CMake can take this all over. However the VS/MSbuild 
option doesn't depend on that IMO. The only part you should be concerned about 
is the gnucash code itself. All the deps can be considered as sdk, just set 
and forget. The gnucash code itself is already buildable via cmake, so the VS/
Msbuild option is there to try. I'm pretty sure it will fail though as none of 
the current devs has ever tested it (we don't have any native Windows devs 
atm).

> From my experience attempts to build GTK (and deps) on windows is a flying
> circus, though to be fair "MS sets up the Bigtop" and devs just "fill the
> arena" (apologies to the circus professionals out there in analogy
> comparing them to MS), with build tool access (VS) always having been a
> problem and still is even with the community (tracking/spyware/require
> login/tsunami-wave-of-the-future) editions.

As we are a small core team we prefer to reuse the work of others as much as 
possible. The 2.6 series leveraged the packages of the mingw project (using 
mingw-get) and built those packages that were not available via mingw.

2.8 on the other hand switched to mingw64 and we leverage the packages they 
provide to a maximum to avoid having to rebuild everything ourselves. These 
packages are maintained via https://github.com/Alexpux/MINGW-packages on 
github. Packages not available there we build ourselves. For the 2.8 series 
this is managed via jhbuild. This allows us to reuse much of the work already 
done to build gnucash on OS X (which also uses jhbuild).

> There are GTK deps that do build well (are supported) by CMake such as if i
> remember correctly Zlib, LibPNG, LIbjpeg or Jasper, LibTiff, freetype (has
> CMakeLists.txt file), Expat, pcre2 etc.  Pixman(cairo dep) or dgk-pixbuf
> not so much.  Though I have seen where eventhough there is a CMakeList.txt
> file a project is not fully windows supported (MSBuild tools)  where there
> are deps on build environment Cygwin or MSys.  Sometimes its "hey just
> download this dll"  or "Windows binaries" and go to the next step... kinda
> defeating the purpose.
> 
I don't think we have