Re: [GNC-dev] Building on Windows

2019-08-28 Thread Dale Phurrough via gnucash-devel
With this Windows GnuCash discussion, I see several categories of choices
that seem to be in play for Windows. I'll write here my thoughts and invite
you all to add yet more clarity.

*Library and ABI ecosystem:*

   - This is gcc, g++ within msys2 ecosystem while using Linux-esque
   libraries. From my rather short time on GnuCash, I think moving away from
   the Linux-esque libraries and msys2 ABI to an alternative like the VC++
   (Visual C++) ABI/library ecosystem is a *very* large undertaking.

*Compiler:*

   - This is closely linked to the choice of the library/ABI ecosystem.
   - Currently GnuCash Windows uses gcc, g++ within the msys2 ecosystem.
   - gcc/g++ is available on many platforms like Linux, msys2, mingw, etc.
   - VC++ compiler is integrated into the Visual Studio IDE -or- can be
   downloaded separate as part of Microsoft "build tools".
   - VC++ compiler/linker does not compile anything compatible with msys2,
   Linux static/dynamic libraries, or ELF executables. The ABIs are
   incompatible between gcc and vc++
   - Everyone has cmake

*Packager:*

   - I list this to invite an exploration into using/making packages for
   GnuCash Windows dependencies.
   - Visual Studio IDE can use several packaging systems, and they deliver
   libraries for appropriate ABI ecosystems
   - VS Code can use several packaging systems, and they deliver libraries
   for appropriate ABI ecosystems

*Source Code control:*

   - I highlight this because of my personal experience with VS Code and
   the most recently Visual Studio IDE 2019.
   - Both Visual Studio IDE and VS Code support git.
   - Visual Studio IDE's support for git technically works, but is
   unnatural and difficult for main development workflows. This is due to
   legacy pre-git UI workflows and an IDE designed for large teams.
   - VS Code's git integration is excellent. And a free extension for VS
   Code "git lens" is seamless and goes even further. The combination
   surpasses the git capabilities of Visual Studio IDE.

*Editor:*

   - Visual Studio IDE can use compilers in Win32 to make a Win32
   executable. Two examples are VC++ and gcc-in-msys2
   - Visual Studio IDE can use WSL or a remote Linux computer to compile a
   Linux ELF executable.
   - VS Code can use tools in Windows, WSL, remote computers, Macs, or
   Docker containers to compile Windows, Linux ELF, MacOS, Android, ...
   - Both editors integrate with C++ debuggers (e.g. gdb and vc++).
   - VS Code seems to integrate with a wider set of debuggers beyond those.
   - Both editors have intellisense, completion, syntax checking, etc.
   - Both editors have extensions to adapt the editor to a developers'
   needs. The ecosystem for VS Code is vibrant, good evolution, and free. The
   Visual Studio IDE is legacy, conservative, and sometimes fee-based.
   - VS Code might support a wider selection of language/debuggers.
   - Visual Studio IDE might support a more technical set of debugging
   tools (like debugging code running on the GPU) and those tools are
   Microsoft-centric.
   - Both support cmake in their GUI
   - VS Code has a json file you can include with a project that specifies
   the extensions needed for the project, possibly allowing for much easier
   bootstrapping
   
https://code.visualstudio.com/docs/editor/extension-gallery#_workspace-recommended-extensions

*Somewhat related examples and one video*

   - VS Code compiling with MingW
   https://code.visualstudio.com/docs/cpp/config-mingw
   - VS Code compiling with VC++
   https://code.visualstudio.com/docs/cpp/config-msvc
   - Visual Studio IDE compiling with MingW
   
https://devblogs.microsoft.com/cppblog/using-mingw-and-cygwin-with-visual-cpp-and-open-folder/
   - Visual Studio compiling and debugging MingW
   https://channel9.msdn.com/Events/Connect/2017/T220
   - Visual Studio example settings of what they call "msys2"
   
https://docs.microsoft.com/en-us/cpp/build/open-folder-projects-cpp?view=vs-2019#example-configuration-for-gcc


--Dale



On Tue, Aug 27, 2019 at 7:20 PM Geert Janssens 
wrote:

> Op dinsdag 27 augustus 2019 19:00:59 CEST schreef John Ralls:
> > > On Aug 27, 2019, at 1:29 AM, Geert Janssens <
> geert.gnuc...@kobaltwit.be>
> > > wrote:>
> > > Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls:
> > >>> On Aug 26, 2019, at 1:49 AM, Geert Janssens <
> geert.gnuc...@kobaltwit.be>
> > >>> wrote:>
> > >>>
> > >>> Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
> >  I was running gnucash directly from the inst directory and not
> creating
> >  an
> >  installer first.  This explanation makes sense.
> > >>>
> > >>> There you go.
> > >>>
> > >>> It would be nice though to be able to run directly from the inst
> > >>> directory
> > >>> while debugging as it saves time not having to recreate a bundle for
> > >>> each
> > >>> iteration.
> > >>>
> > >>> Frankly I believe this shows how little actual development really
> > >>> happens
> > >>> on Windows. 

Re: [GNC-dev] Building on Windows

2019-08-27 Thread Geert Janssens
Op dinsdag 27 augustus 2019 19:00:59 CEST schreef John Ralls:
> > On Aug 27, 2019, at 1:29 AM, Geert Janssens 
> > wrote:> 
> > Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls:
> >>> On Aug 26, 2019, at 1:49 AM, Geert Janssens 
> >>> wrote:>
> >>> 
> >>> Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
>  I was running gnucash directly from the inst directory and not creating
>  an
>  installer first.  This explanation makes sense.
> >>> 
> >>> There you go.
> >>> 
> >>> It would be nice though to be able to run directly from the inst
> >>> directory
> >>> while debugging as it saves time not having to recreate a bundle for
> >>> each
> >>> iteration.
> >>> 
> >>> Frankly I believe this shows how little actual development really
> >>> happens
> >>> on Windows. Because of that the development experience is not really
> >>> optimized on that platform. With you actively doing so, it may be
> >>> helpful
> >>> to share your experiences so we may make it more attractive for other
> >>> Windows oriented contributors.
> >> 
> >> Has anyone tried Windows Subsystem for Linux
> >> (https://docs.microsoft.com/en-us/windows/wsl/install-win10)? That might
> >> be
> >> a less painful development environment for Windows users at least in the
> >> short term.
> > 
> > I haven't tried it - as far as I know it's not available on Win7.
> > 
> > But as others have already pointed out there are limitations:
> > - from what I have heard it doesn't support GUI applications very well
> > (yet). It is said to be more oriented towards command line utilities.
> > - WSL is a virtual machine, so you'd be running a linux application in a
> > VM, not a native application. Granted, the VM is deeply integrated in
> > Windows so for many users the difference may be hardly noticeable.
> > 
> >> Longer term I think we need to figure out how to make GnuCash buildable
> >> in
> >> Visual Studio. Recent releases provide for a Clang toolchain as well as
> >> the
> >> standard MSVC++ one. We might be able to create a build environment
> >> combined with vcpkg (https://github.com/microsoft/vcpkg) that would be
> >> more
> >> stable, offer a lower barrier to entry, and generate
> >> windows-understandable
> >> debug info.
> > 
> > That would indeed be a more interesting approach. Would that mean we'd
> > have to build the gnucash dependencies in VS as well ? (Aqbanking, guile,
> > webkit,...) Or can VS code link to code built with mingw ? If the latter
> > we could transition in phases: first get GnuCash built and run on VS,
> > while keeping the dependencies as they are, then gradually migrate
> > dependencies (if we want to have the same debug benefits there).
> 
> Win7 goes out of support at the end of the year, meaning only really serious
> security bugs will be fixed (as happened recently with XP). You really
> should upgrade soon.
> 
Will GnuCash stop supporting Win7 as well by that time ? That's my only reason 
to stick to that old platform.

> Let's please be strict about terminology here, it's important: Visual Studio
> (VS) is an IDE like Eclipse. The  Microsoft compiler is Visual C/C++
> (MSVC).
> 
Which I have learned by now from your repeated corrections. Thanks :)
I hope to remember it.

> Yes, MinGW and MSVC libraries with C linkage can be linked at will. MinGW
> links the MS runtime, msvcrt, after all. The issue is C++ libraries using
> C++ linkage. I'm pretty sure that MSVC and gcc use different mangling so
> C++ libraries won't interlink. LLVM [1] mangling depends on what platform
> it's building for, https://clang.llvm.org/docs/MSVCCompatibility.html. That
> probably means that we'll have to build boost before we can build GnuCash.

So we have options it seems.
We could start by figuring out what tweaks would be needed to allow Windows 
devs to use VS with gcc. As our complete Windows build system currently 
depends on gcc, that should be relatively little effort. That still presumes 
we use our own build scripts to set compile all the dependencies, but I hope 
with having done that once and setting a few paths or environment variables in 
a VS project, working on gnucash itself may be reasonably little effort.
>From there we could start to work out if the other dependencies could be 
brought under VS as well or we could release gnucash SDK's, being a pre-
wrapped/pre-built set of dependencies to reduce the getting started overhead.
LLVM or MSVC use can be a separate project.
If a similar thing can be set up as tasks in the VS Code editor, that's yet 
another option.
Now we just need someone to do the experiments. Would have been an interesting 
GSOC project IMO..

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread John Ralls



> On Aug 27, 2019, at 1:29 AM, Geert Janssens  
> wrote:
> 
> Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls:
>>> On Aug 26, 2019, at 1:49 AM, Geert Janssens 
>>> wrote:> 
>>> Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
 I was running gnucash directly from the inst directory and not creating
 an
 installer first.  This explanation makes sense.
>>> 
>>> There you go.
>>> 
>>> It would be nice though to be able to run directly from the inst directory
>>> while debugging as it saves time not having to recreate a bundle for each
>>> iteration.
>>> 
>>> Frankly I believe this shows how little actual development really happens
>>> on Windows. Because of that the development experience is not really
>>> optimized on that platform. With you actively doing so, it may be helpful
>>> to share your experiences so we may make it more attractive for other
>>> Windows oriented contributors.
>> 
>> Has anyone tried Windows Subsystem for Linux
>> (https://docs.microsoft.com/en-us/windows/wsl/install-win10)? That might be
>> a less painful development environment for Windows users at least in the
>> short term.
>> 
> I haven't tried it - as far as I know it's not available on Win7.
> 
> But as others have already pointed out there are limitations:
> - from what I have heard it doesn't support GUI applications very well (yet). 
> It is said to be more oriented towards command line utilities.
> - WSL is a virtual machine, so you'd be running a linux application in a VM, 
> not a native application. Granted, the VM is deeply integrated in Windows so 
> for many users the difference may be hardly noticeable.
> 
>> Longer term I think we need to figure out how to make GnuCash buildable in
>> Visual Studio. Recent releases provide for a Clang toolchain as well as the
>> standard MSVC++ one. We might be able to create a build environment
>> combined with vcpkg (https://github.com/microsoft/vcpkg) that would be more
>> stable, offer a lower barrier to entry, and generate windows-understandable
>> debug info.
> 
> That would indeed be a more interesting approach. Would that mean we'd have 
> to 
> build the gnucash dependencies in VS as well ? (Aqbanking, guile, webkit,...) 
> Or can VS code link to code built with mingw ? If the latter we could 
> transition in phases: first get GnuCash built and run on VS, while keeping 
> the 
> dependencies as they are, then gradually migrate dependencies (if we want to 
> have the same debug benefits there).

Win7 goes out of support at the end of the year, meaning only really serious 
security bugs will be fixed (as happened recently with XP). You really should 
upgrade soon.

Let's please be strict about terminology here, it's important: Visual Studio 
(VS) is an IDE like Eclipse. The  Microsoft compiler is Visual C/C++ (MSVC). 

Yes, MinGW and MSVC libraries with C linkage can be linked at will. MinGW links 
the MS runtime, msvcrt, after all. The issue is C++ libraries using C++ 
linkage. I'm pretty sure that MSVC and gcc use different mangling so C++ 
libraries won't interlink. LLVM [1] mangling depends on what platform it's 
building for, https://clang.llvm.org/docs/MSVCCompatibility.html. That probably 
means that we'll have to build boost before we can build GnuCash.

Regards,
John Ralls

[1] VS 2019 can build CMake projects using Clang: 
https://devblogs.microsoft.com/cppblog/clang-llvm-support-in-visual-studio/ and 
that might mangle the sa





___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread Adrien Monteleone
> On Aug 27, 2019 w35d239, at 11:01 AM, John Ralls  wrote:
> 
> 
> VSCode can't build anything, it's just an editor. But it can call[1] out to 
> the build system to do whatever build for whatever platform you like. Visual 
> Studio is the full-featured IDE and there's a free (as in beer, Microsoft 
> hasn't gotten *that* far down the open source road!) version [2]. There's 
> even a Mac version[3] that's probably better than Xcode, though admittedly 
> that's not saying much.

And probably why it is seemingly used primarily for web based development so 
far.

> 
> I don't know much about WSL, I was wondering out loud.

WSL was not-so-allegedly created so devs can stick with the MS desktop and 
develop for Linux on it. (primarily) It runs (as of v2) a real Linux kernel in 
a Win10 managed ‘utility’ VM with very little overhead or performance hit. The 
code executed is ‘Linux’ code. Some potential uses are to run Linux apps ‘on’ 
Windows desktops with a native feel and performance. (supposedly WSL2 will 
achieve that)

It stems some bleeding of devs away from the MS platform, but also makes it 
easier for MS devs to work on the Linux kernel which they have started 
contributing to. (probably for WSL, a bit circular) Note, that sentence is pure 
conjecture from the interwebs.

There is some evidence for this with the new VSCode Remote which is an 
extension where you run VSCode on windows, but ‘remote into’ WSL: 
https://code.visualstudio.com/docs/remote/wsl (making it easy to stick with 
Windows, but still develop for Linux)

Regards,
Adrien

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread John Ralls
My understanding, and the link you posted does nothing to gainsay it, is that 
VSCode is an editor like emacs. You need other tools to do the building, 
packaging, and debugging. Like emacs, those tools can be integrated with the 
editor via tasks (link in previous email).

What's your full setup for development using VSCode? How much effort is needed 
to duplicate it?

Regards,
John Ralls


> On Aug 27, 2019, at 5:37 AM, Dale Phurrough via gnucash-devel 
>  wrote:
> 
> I noticed earlier the use of "VS" and was watching it for context. Now I
> see more clearly what was intended.
> You want to actually use the Visual Studio UI and the Visual Studio
> compiler. And consider VS Code a lesser option "at a stretch".
> 
> I've tons of experience with Visual Studio. It is good for legacy Visual
> Studio projects, large in-house teams, and rigid development cycles. None
> of those three align well with GnuCash.
> Contrast that to VS Code. Personally, I use it for everything now. And I
> use it across platforms, across projects, and always with open-source
> projects.
> 
> This "windows developer" that you are seeking...are you sure they want
> Visual Studio? Or is VS Code a better fit? I ask because the approach one
> takes will be different between the two; and likely not worth the effort to
> support both.
> Each of the two will have their own possibilities of: editor, packager, and
> compiler/linker. Luckily, there is some overlap.
> Here is recently statistics and reports on dev tool use VS Code and Visual
> Studio. VS Code is ahead and the younger devs (via hires) prefer it.
> https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx
> 
> 
> 
> On Tue, Aug 27, 2019 at 1:52 PM Geert Janssens 
> wrote:
> 
>> Thanks for the suggestion. However the goal is not only to get a linux
>> GnuCash
>> running on Windows. We already do better than that so it would be a step
>> back
>> to what we do now.
>> The goal is to make it easy to develop GnuCash *natively* on Windows ("as
>> easy
>> as on linux") to make it more attractive for native Windows developers to
>> join
>> the effort. Having a native Windows developer go through the hoops of
>> MingW/
>> MSYS or even docker with linux is to high a barrier. Those are not the
>> tools
>> of choice for a Windows developer. Visual Studio is the environment of
>> choice,
>> or the lighter VS Code at a stretch. Want Windows developers to be
>> interested
>> ? Make sure they can continue to use their tools.
>> 
>> Regards,
>> 
>> Geert
>> 
>> Op dinsdag 27 augustus 2019 12:58:47 CEST schreef Dale Phurrough via
>> gnucash-
>> devel:
>>> If your goal is to use a Windows computer to run and/or develop GnuCash,
>>> then an option is to...
>>> Execute GnuCash in Linux
>>> Display GnuCash in Windows
>>> 
>>> I do not recommend deep investment into the current WSL. The drastically
>>> different WSL2 is already in preview and will be available within ~6-9
>>> months. At that point, there will be a full Linux kernel available. If it
>>> works in WSL1, it will probably work in WSL2...but you will likely have
>>> many workarounds/hacks that will be obsolete.
>>> Do Linux work in a Docker container. Host that container either on
>> Windows
>>> or on any Linux machine you have that can run Docker.
>>> Use X Windows to remote the GnuCash display from the Docker container to
>>> your Windows machine. This is standard XWindows remoting.
>>> Now you have GnuCash GUI being displayed on a Windows machine, GnuCash
>>> executable running in the Docker container wherever it is, and the X
>>> Windows protocol connecting the two together.
>>> I do this often, across many Linux OS, all remoted to my same Windows 10
>>> computer.
>>> And yes, you can run the Docker container on same same Windows computer
>>> showing the GUI.
>>> 
>>> 1. Get a working Docker install. This is easy. Available for Windows and
>>> every Linux distribution https://docs.docker.com/install/
>>> 2. Get a working XWindows install for Windows. I use cygwin's XWin
>> because
>>> setup was easy and it is free. https://x.cygwin.com/
>>> 3. Get a working GnuCash Docker container. This is easy
>>> https://github.com/diablodale/gnucash-dev-docker
>>> 
>>> --Dale
>>> 
>>> On Tue, Aug 27, 2019 at 7:15 AM Adrien Monteleone <
>>> 
>>> adrien.montele...@lusfiber.net> wrote:
> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj <
 
 bhardw...@outlook.com> wrote:
> WSL would provide a Linux binary, not a Windows binary. Is that what
>> you
 
 are thinking of building? I am also not sure how to get GUI running for
 WSL. (WSL is really good tool.)
 
 That’s what I was thinking too, but maybe John knows something we
>> don’t.
 If the goal of being able to build via VSCode is reached, then you can
>> use
 one machine and do both builds, one for Linux, the other for Windows.
>> I’ve
 not heard that the Linux version of VSCode can build a Windows binary.
 (would be great if it 

Re: [GNC-dev] Building on Windows

2019-08-27 Thread Adrien Monteleone
Interesting.

Also very interesting, is this graph form the survey showing how the 
technologies relate to each other, and from that one *might* surmise the use 
cases:

https://insights.stackoverflow.com/survey/2018#correlated-technologies

If I’m reading that correctly, it looks like VSCode is the preferred IDE for 
JS/TS developers for web applications. Devs working more directly on Windows 
Desktop seem to prefer the full VS, but that might also be affected by the 
demographics - younger developers are preferring VSCode and they are 
gravitating towards web platforms rather than desktop.

> On Aug 27, 2019 w35d239, at 7:37 AM, Dale Phurrough  wrote:
> 
> I noticed earlier the use of "VS" and was watching it for context. Now I see 
> more clearly what was intended.
> You want to actually use the Visual Studio UI and the Visual Studio compiler. 
> And consider VS Code a lesser option "at a stretch".
> 
> I've tons of experience with Visual Studio. It is good for legacy Visual 
> Studio projects, large in-house teams, and rigid development cycles. None of 
> those three align well with GnuCash.
> Contrast that to VS Code. Personally, I use it for everything now. And I use 
> it across platforms, across projects, and always with open-source projects.
> 
> This "windows developer" that you are seeking...are you sure they want Visual 
> Studio? Or is VS Code a better fit? I ask because the approach one takes will 
> be different between the two; and likely not worth the effort to support both.
> Each of the two will have their own possibilities of: editor, packager, and 
> compiler/linker. Luckily, there is some overlap.
> Here is recently statistics and reports on dev tool use VS Code and Visual 
> Studio. VS Code is ahead and the younger devs (via hires) prefer it.
> https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread John Ralls


> On Aug 26, 2019, at 10:15 PM, Adrien Monteleone 
>  wrote:
> 
> 
>> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj  
>> wrote:
>> 
>> WSL would provide a Linux binary, not a Windows binary. Is that what you are 
>> thinking of building? I am also not sure how to get GUI running for WSL. 
>> (WSL is really good tool.)
> 
> That’s what I was thinking too, but maybe John knows something we don’t. If 
> the goal of being able to build via VSCode is reached, then you can use one 
> machine and do both builds, one for Linux, the other for Windows. I’ve not 
> heard that the Linux version of VSCode can build a Windows binary. (would be 
> great if it could)
> 
> As for the GUI, some people have done it, though MS doesn’t support it. (even 
> running GnuCash!) But I haven’t tried it myself. I’m just getting ready to 
> play with Win10 for a client (I don’t use Win systems regularly anymore) so I 
> might give it a go in a month or so.

VSCode can't build anything, it's just an editor. But it can call[1] out to the 
build system to do whatever build for whatever platform you like. Visual Studio 
is the full-featured IDE and there's a free (as in beer, Microsoft hasn't 
gotten *that* far down the open source road!) version [2]. There's even a Mac 
version[3] that's probably better than Xcode, though admittedly that's not 
saying much.

I don't know much about WSL, I was wondering out loud.

Regards,
John Ralls


[1] https://code.visualstudio.com/docs/editor/tasks
[2] https://visualstudio.microsoft.com/downloads/
[3] https://visualstudio.microsoft.com/vs/mac/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread Geert Janssens
Op dinsdag 27 augustus 2019 14:37:21 CEST schreef Dale Phurrough:
> I noticed earlier the use of "VS" and was watching it for context. Now I
> see more clearly what was intended.
> You want to actually use the Visual Studio UI and the Visual Studio
> compiler. And consider VS Code a lesser option "at a stretch".
> 
> I've tons of experience with Visual Studio. It is good for legacy Visual
> Studio projects, large in-house teams, and rigid development cycles. None
> of those three align well with GnuCash.
> Contrast that to VS Code. Personally, I use it for everything now. And I
> use it across platforms, across projects, and always with open-source
> projects.
> 
> This "windows developer" that you are seeking...are you sure they want
> Visual Studio? Or is VS Code a better fit? I ask because the approach one
> takes will be different between the two; and likely not worth the effort to
> support both.
> Each of the two will have their own possibilities of: editor, packager, and
> compiler/linker. Luckily, there is some overlap.
> Here is recently statistics and reports on dev tool use VS Code and Visual
> Studio. VS Code is ahead and the younger devs (via hires) prefer it.
> https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx

Well, this shows I'm not a Windows developer myself. The way I was told Visual 
Studio was the full product and VS Code a lightweight open sourced edition. 
That may be totally off. So based on your feedback VS Code support is what we 
should focus on. From what I understand that's a cross-platform IDE so we 
could even experiment with it on linux. Though the same applies in the other 
direction of course: linux users have *their* preferred tools and habits :)

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread Dale Phurrough via gnucash-devel
I noticed earlier the use of "VS" and was watching it for context. Now I
see more clearly what was intended.
You want to actually use the Visual Studio UI and the Visual Studio
compiler. And consider VS Code a lesser option "at a stretch".

I've tons of experience with Visual Studio. It is good for legacy Visual
Studio projects, large in-house teams, and rigid development cycles. None
of those three align well with GnuCash.
Contrast that to VS Code. Personally, I use it for everything now. And I
use it across platforms, across projects, and always with open-source
projects.

This "windows developer" that you are seeking...are you sure they want
Visual Studio? Or is VS Code a better fit? I ask because the approach one
takes will be different between the two; and likely not worth the effort to
support both.
Each of the two will have their own possibilities of: editor, packager, and
compiler/linker. Luckily, there is some overlap.
Here is recently statistics and reports on dev tool use VS Code and Visual
Studio. VS Code is ahead and the younger devs (via hires) prefer it.
https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx



On Tue, Aug 27, 2019 at 1:52 PM Geert Janssens 
wrote:

> Thanks for the suggestion. However the goal is not only to get a linux
> GnuCash
> running on Windows. We already do better than that so it would be a step
> back
> to what we do now.
> The goal is to make it easy to develop GnuCash *natively* on Windows ("as
> easy
> as on linux") to make it more attractive for native Windows developers to
> join
> the effort. Having a native Windows developer go through the hoops of
> MingW/
> MSYS or even docker with linux is to high a barrier. Those are not the
> tools
> of choice for a Windows developer. Visual Studio is the environment of
> choice,
> or the lighter VS Code at a stretch. Want Windows developers to be
> interested
> ? Make sure they can continue to use their tools.
>
> Regards,
>
> Geert
>
> Op dinsdag 27 augustus 2019 12:58:47 CEST schreef Dale Phurrough via
> gnucash-
> devel:
> > If your goal is to use a Windows computer to run and/or develop GnuCash,
> > then an option is to...
> > Execute GnuCash in Linux
> > Display GnuCash in Windows
> >
> > I do not recommend deep investment into the current WSL. The drastically
> > different WSL2 is already in preview and will be available within ~6-9
> > months. At that point, there will be a full Linux kernel available. If it
> > works in WSL1, it will probably work in WSL2...but you will likely have
> > many workarounds/hacks that will be obsolete.
> > Do Linux work in a Docker container. Host that container either on
> Windows
> > or on any Linux machine you have that can run Docker.
> > Use X Windows to remote the GnuCash display from the Docker container to
> > your Windows machine. This is standard XWindows remoting.
> > Now you have GnuCash GUI being displayed on a Windows machine, GnuCash
> > executable running in the Docker container wherever it is, and the X
> > Windows protocol connecting the two together.
> > I do this often, across many Linux OS, all remoted to my same Windows 10
> > computer.
> > And yes, you can run the Docker container on same same Windows computer
> > showing the GUI.
> >
> > 1. Get a working Docker install. This is easy. Available for Windows and
> > every Linux distribution https://docs.docker.com/install/
> > 2. Get a working XWindows install for Windows. I use cygwin's XWin
> because
> > setup was easy and it is free. https://x.cygwin.com/
> > 3. Get a working GnuCash Docker container. This is easy
> > https://github.com/diablodale/gnucash-dev-docker
> >
> > --Dale
> >
> > On Tue, Aug 27, 2019 at 7:15 AM Adrien Monteleone <
> >
> > adrien.montele...@lusfiber.net> wrote:
> > > > On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj <
> > >
> > > bhardw...@outlook.com> wrote:
> > > > WSL would provide a Linux binary, not a Windows binary. Is that what
> you
> > >
> > > are thinking of building? I am also not sure how to get GUI running for
> > > WSL. (WSL is really good tool.)
> > >
> > > That’s what I was thinking too, but maybe John knows something we
> don’t.
> > > If the goal of being able to build via VSCode is reached, then you can
> use
> > > one machine and do both builds, one for Linux, the other for Windows.
> I’ve
> > > not heard that the Linux version of VSCode can build a Windows binary.
> > > (would be great if it could)
> > >
> > > As for the GUI, some people have done it, though MS doesn’t support it.
> > > (even running GnuCash!) But I haven’t tried it myself. I’m just getting
> > > ready to play with Win10 for a client (I don’t use Win systems
> regularly
> > > anymore) so I might give it a go in a month or so.
> > >
> > > Regards,
> > > Adrien
> > >
> > >
> > > ___
> > > gnucash-devel mailing list
> > > gnucash-devel@gnucash.org
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> > 

Re: [GNC-dev] Building on Windows

2019-08-27 Thread Geert Janssens
Thanks for the suggestion. However the goal is not only to get a linux GnuCash 
running on Windows. We already do better than that so it would be a step back 
to what we do now.
The goal is to make it easy to develop GnuCash *natively* on Windows ("as easy 
as on linux") to make it more attractive for native Windows developers to join 
the effort. Having a native Windows developer go through the hoops of MingW/
MSYS or even docker with linux is to high a barrier. Those are not the tools 
of choice for a Windows developer. Visual Studio is the environment of choice, 
or the lighter VS Code at a stretch. Want Windows developers to be interested 
? Make sure they can continue to use their tools.

Regards,

Geert

Op dinsdag 27 augustus 2019 12:58:47 CEST schreef Dale Phurrough via gnucash-
devel:
> If your goal is to use a Windows computer to run and/or develop GnuCash,
> then an option is to...
> Execute GnuCash in Linux
> Display GnuCash in Windows
> 
> I do not recommend deep investment into the current WSL. The drastically
> different WSL2 is already in preview and will be available within ~6-9
> months. At that point, there will be a full Linux kernel available. If it
> works in WSL1, it will probably work in WSL2...but you will likely have
> many workarounds/hacks that will be obsolete.
> Do Linux work in a Docker container. Host that container either on Windows
> or on any Linux machine you have that can run Docker.
> Use X Windows to remote the GnuCash display from the Docker container to
> your Windows machine. This is standard XWindows remoting.
> Now you have GnuCash GUI being displayed on a Windows machine, GnuCash
> executable running in the Docker container wherever it is, and the X
> Windows protocol connecting the two together.
> I do this often, across many Linux OS, all remoted to my same Windows 10
> computer.
> And yes, you can run the Docker container on same same Windows computer
> showing the GUI.
> 
> 1. Get a working Docker install. This is easy. Available for Windows and
> every Linux distribution https://docs.docker.com/install/
> 2. Get a working XWindows install for Windows. I use cygwin's XWin because
> setup was easy and it is free. https://x.cygwin.com/
> 3. Get a working GnuCash Docker container. This is easy
> https://github.com/diablodale/gnucash-dev-docker
> 
> --Dale
> 
> On Tue, Aug 27, 2019 at 7:15 AM Adrien Monteleone <
> 
> adrien.montele...@lusfiber.net> wrote:
> > > On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj <
> > 
> > bhardw...@outlook.com> wrote:
> > > WSL would provide a Linux binary, not a Windows binary. Is that what you
> > 
> > are thinking of building? I am also not sure how to get GUI running for
> > WSL. (WSL is really good tool.)
> > 
> > That’s what I was thinking too, but maybe John knows something we don’t.
> > If the goal of being able to build via VSCode is reached, then you can use
> > one machine and do both builds, one for Linux, the other for Windows. I’ve
> > not heard that the Linux version of VSCode can build a Windows binary.
> > (would be great if it could)
> > 
> > As for the GUI, some people have done it, though MS doesn’t support it.
> > (even running GnuCash!) But I haven’t tried it myself. I’m just getting
> > ready to play with Win10 for a client (I don’t use Win systems regularly
> > anymore) so I might give it a go in a month or so.
> > 
> > Regards,
> > Adrien
> > 
> > 
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread Dale Phurrough via gnucash-devel
If your goal is to use a Windows computer to run and/or develop GnuCash,
then an option is to...
Execute GnuCash in Linux
Display GnuCash in Windows

I do not recommend deep investment into the current WSL. The drastically
different WSL2 is already in preview and will be available within ~6-9
months. At that point, there will be a full Linux kernel available. If it
works in WSL1, it will probably work in WSL2...but you will likely have
many workarounds/hacks that will be obsolete.
Do Linux work in a Docker container. Host that container either on Windows
or on any Linux machine you have that can run Docker.
Use X Windows to remote the GnuCash display from the Docker container to
your Windows machine. This is standard XWindows remoting.
Now you have GnuCash GUI being displayed on a Windows machine, GnuCash
executable running in the Docker container wherever it is, and the X
Windows protocol connecting the two together.
I do this often, across many Linux OS, all remoted to my same Windows 10
computer.
And yes, you can run the Docker container on same same Windows computer
showing the GUI.

1. Get a working Docker install. This is easy. Available for Windows and
every Linux distribution https://docs.docker.com/install/
2. Get a working XWindows install for Windows. I use cygwin's XWin because
setup was easy and it is free. https://x.cygwin.com/
3. Get a working GnuCash Docker container. This is easy
https://github.com/diablodale/gnucash-dev-docker

--Dale

On Tue, Aug 27, 2019 at 7:15 AM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

>
> > On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj <
> bhardw...@outlook.com> wrote:
> >
> > WSL would provide a Linux binary, not a Windows binary. Is that what you
> are thinking of building? I am also not sure how to get GUI running for
> WSL. (WSL is really good tool.)
>
> That’s what I was thinking too, but maybe John knows something we don’t.
> If the goal of being able to build via VSCode is reached, then you can use
> one machine and do both builds, one for Linux, the other for Windows. I’ve
> not heard that the Linux version of VSCode can build a Windows binary.
> (would be great if it could)
>
> As for the GUI, some people have done it, though MS doesn’t support it.
> (even running GnuCash!) But I haven’t tried it myself. I’m just getting
> ready to play with Win10 for a client (I don’t use Win systems regularly
> anymore) so I might give it a go in a month or so.
>
> Regards,
> Adrien
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-27 Thread Geert Janssens
Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls:
> > On Aug 26, 2019, at 1:49 AM, Geert Janssens 
> > wrote:> 
> > Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
> >> I was running gnucash directly from the inst directory and not creating
> >> an
> >> installer first.  This explanation makes sense.
> > 
> > There you go.
> > 
> > It would be nice though to be able to run directly from the inst directory
> > while debugging as it saves time not having to recreate a bundle for each
> > iteration.
> > 
> > Frankly I believe this shows how little actual development really happens
> > on Windows. Because of that the development experience is not really
> > optimized on that platform. With you actively doing so, it may be helpful
> > to share your experiences so we may make it more attractive for other
> > Windows oriented contributors.
> 
> Has anyone tried Windows Subsystem for Linux
> (https://docs.microsoft.com/en-us/windows/wsl/install-win10)? That might be
> a less painful development environment for Windows users at least in the
> short term.
> 
I haven't tried it - as far as I know it's not available on Win7.

But as others have already pointed out there are limitations:
- from what I have heard it doesn't support GUI applications very well (yet). 
It is said to be more oriented towards command line utilities.
- WSL is a virtual machine, so you'd be running a linux application in a VM, 
not a native application. Granted, the VM is deeply integrated in Windows so 
for many users the difference may be hardly noticeable.

> Longer term I think we need to figure out how to make GnuCash buildable in
> Visual Studio. Recent releases provide for a Clang toolchain as well as the
> standard MSVC++ one. We might be able to create a build environment
> combined with vcpkg (https://github.com/microsoft/vcpkg) that would be more
> stable, offer a lower barrier to entry, and generate windows-understandable
> debug info.

That would indeed be a more interesting approach. Would that mean we'd have to 
build the gnucash dependencies in VS as well ? (Aqbanking, guile, webkit,...) 
Or can VS code link to code built with mingw ? If the latter we could 
transition in phases: first get GnuCash built and run on VS, while keeping the 
dependencies as they are, then gradually migrate dependencies (if we want to 
have the same debug benefits there).

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-26 Thread Adrien Monteleone

> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj  
> wrote:
> 
> WSL would provide a Linux binary, not a Windows binary. Is that what you are 
> thinking of building? I am also not sure how to get GUI running for WSL. (WSL 
> is really good tool.)

That’s what I was thinking too, but maybe John knows something we don’t. If the 
goal of being able to build via VSCode is reached, then you can use one machine 
and do both builds, one for Linux, the other for Windows. I’ve not heard that 
the Linux version of VSCode can build a Windows binary. (would be great if it 
could)

As for the GUI, some people have done it, though MS doesn’t support it. (even 
running GnuCash!) But I haven’t tried it myself. I’m just getting ready to play 
with Win10 for a client (I don’t use Win systems regularly anymore) so I might 
give it a go in a month or so.

Regards,
Adrien


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-26 Thread Sumit Bhardwaj
WSL would provide a Linux binary, not a Windows binary. Is that what you are 
thinking of building? I am also not sure how to get GUI running for WSL. (WSL 
is really good tool.)

MSVC clang support is improving fast. When I downloaded GnuCash source code, 
the challenge was missing dependencies. I haven't tried it after that, but I 
can try and report back.

-Sumit
 
-Original Message-
From: gnucash-devel  
On Behalf Of John Ralls
Sent: Monday, August 26, 2019 09:33
To: Geert Janssens 
Cc: gnucash-devel@gnucash.org; Matthew Forbis 
Subject: Re: [GNC-dev] Building on Windows



> On Aug 26, 2019, at 1:49 AM, Geert Janssens  
> wrote:
> 
> Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
>> I was running gnucash directly from the inst directory and not 
>> creating an installer first.  This explanation makes sense.
>> 
> 
> There you go.
> 
> It would be nice though to be able to run directly from the inst 
> directory while debugging as it saves time not having to recreate a 
> bundle for each iteration.
> 
> Frankly I believe this shows how little actual development really 
> happens on Windows. Because of that the development experience is not 
> really optimized on that platform. With you actively doing so, it may 
> be helpful to share your experiences so we may make it more attractive 
> for other Windows oriented contributors.

Has anyone tried Windows Subsystem for Linux 
(https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwsl%2Finstall-win10data=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942sdata=TSQl1pt%2B1XoY%2BP7MU%2BDFoneh4xUiiHZjypyf6YPJw%2Bk%3Dreserved=0)?
 That might be a less painful development environment for Windows users at 
least in the short term.

Longer term I think we need to figure out how to make GnuCash buildable in 
Visual Studio. Recent releases provide for a Clang toolchain as well as the 
standard MSVC++ one. We might be able to create a build environment combined 
with vcpkg 
(https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkgdata=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942sdata=jnvhX6%2FizBe%2Fn5ERFcKGvs6WSjT1oZushJ%2BhHwhlQZY%3Dreserved=0)
 that would be more stable, offer a lower barrier to entry, and generate 
windows-understandable debug info.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-develdata=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942sdata=VYw%2BkXmJkGDKza2sikiz7aLNctqrpbdT119bqc2ndI4%3Dreserved=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-26 Thread John Ralls



> On Aug 26, 2019, at 1:49 AM, Geert Janssens  
> wrote:
> 
> Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
>> I was running gnucash directly from the inst directory and not creating an
>> installer first.  This explanation makes sense.
>> 
> 
> There you go.
> 
> It would be nice though to be able to run directly from the inst directory 
> while debugging as it saves time not having to recreate a bundle for each 
> iteration.
> 
> Frankly I believe this shows how little actual development really happens on 
> Windows. Because of that the development experience is not really optimized 
> on 
> that platform. With you actively doing so, it may be helpful to share your 
> experiences so we may make it more attractive for other Windows oriented 
> contributors.

Has anyone tried Windows Subsystem for Linux 
(https://docs.microsoft.com/en-us/windows/wsl/install-win10)? That might be a 
less painful development environment for Windows users at least in the short 
term.

Longer term I think we need to figure out how to make GnuCash buildable in 
Visual Studio. Recent releases provide for a Clang toolchain as well as the 
standard MSVC++ one. We might be able to create a build environment combined 
with vcpkg (https://github.com/microsoft/vcpkg) that would be more stable, 
offer a lower barrier to entry, and generate windows-understandable debug info.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-26 Thread Geert Janssens
Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
>  I was running gnucash directly from the inst directory and not creating an
> installer first.  This explanation makes sense.
> 

There you go.

It would be nice though to be able to run directly from the inst directory 
while debugging as it saves time not having to recreate a bundle for each 
iteration.

Frankly I believe this shows how little actual development really happens on 
Windows. Because of that the development experience is not really optimized on 
that platform. With you actively doing so, it may be helpful to share your 
experiences so we may make it more attractive for other Windows oriented 
contributors.

This issue is a good example.

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-26 Thread Geert Janssens
Op zaterdag 24 augustus 2019 18:22:42 CEST schreef John Ralls:
> > On Aug 23, 2019, at 11:28 PM, Geert Janssens 
> > wrote:
> > 
> > Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via
> > gnucash-> 
> > devel:
> >> I have finally had time to sit down and try again.  When libxml
> >> development
> >> was installed via pacman, it installed icu64 in addition to the icu61
> >> that
> >> was already installed by the gnucash script.  I was able to remove icu64
> >> and clear out the entire build and inst directories and try again.  It
> >> built without errors at that point and then the first time I ran, it
> >> crashed.  I had to do a glib-compile-schemas in order for it to run at
> >> that
> >> point.  (I'm just documenting manual interactions in case the scripts
> >> should be updated some for others).
> >> 
> >> Thanks all for your help so far.  Now onto trying to debug the chart hang
> >> problem.
> > 
> > Thanks for the feedback.
> > 
> > How exactly did you run gnucash ?
> > 
> > I think the whole windows build system is set up to create a Windows
> > installer for the gnucash package and run gnucash after this installer
> > has run.
> > 
> > On the other hand, if simply running the glib-compile-schemas on the end
> > result of the build script helps you run it without invoking the Windows
> > installer, that's a worthwile bonus.
> > 
> > I *thought* we did run this while building, but a quick scan of the build
> > scripts suggest it's only run while bundling gnucash. I wonder why that
> > is.
> > Perhaps John remembers.
> 
> Because everything else that uses GSettings is built by MinGW, because
> there's no need for GSettings during the build process and
> glib-compile-schemas is comprehensive so running it once at the end does
> the job.
> 
I may not have been very clear. I do understand all that. However I was 
thinking of the ability to run from the build directory while debugging. From 
what I understand that requires glib-compile-schemas to run once at the end of 
the build process.

> IIRC we disabled compiling the schemas at build time because it set up the
> paths for the build directory and so the compiled schemas failed after the
> install step.
> 
I had to refresh my memory and dug a bit through the various code bits. IUIC 
the issue may be slightly more nuanced.

>From what I understand the gschemas.compile file only holds information on the 
schema files it finds during compilation (obviously). During build the compile 
step will only find the gnucash gschema files. However as gnucash relies on 
gtk as well, it also needs the gtk gschema files at run time.

So if we want to run gnucash directly from the build directory [1], gnucash 
needs to find those files as well. As long as gnucash is run from a mingw32 
shell, they should be found as in that environment the gtk gschemas will be 
installed in mingw's default system location, and ours are installed in the 
build dir.

The same should be valid for running directly from the install location (the 
one where 'make install' puts the files).

However when bundling everything in the installer, suddenly the gtk and 
gnucash gschemas end up in the same directory, and both gtk and gnucash have a 
gschemas.compiled file available for bundling. And those files
a. only cover their respective gschema files
b. want to be installed in the same location with the same name
So for the installer a new one has to be generated that covers all gschema 
files that are part of the bundle.

To be fair I'm not sure the gschema compilation would be the only missing 
piece to allow running directly from build or inst. I do think on the other 
hand this particular issue may be solvable fairly easily. (I have fired up my 
Windows build to experiment with this).

> As for the build system set up, build_package.ps1 does indeed build a
> setup.exe for distribution and even uploads it to the distribution server
> if provided with an upload URI. For other purposes the build system does
> require a bit of manual intervention. That's equally true on Unix including
> MacOS.

As far as I know nothing has to be done in particular on linux. I can run
cmake with a custom install path, build/install and then run gnucash from 
where it got installed. I'm probably so used to it I forgot that's not the 
case on the other platforms.

Regards,

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-24 Thread Matthew Forbis via gnucash-devel
 I was running gnucash directly from the inst directory and not creating an 
installer first.  This explanation makes sense.

Thanks,Matt

On Saturday, August 24, 2019, 11:22:48 AM CDT, John Ralls 
 wrote:  
 
 

> On Aug 23, 2019, at 11:28 PM, Geert Janssens  
> wrote:
> 
> Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash-
> devel:
>> I have finally had time to sit down and try again.  When libxml development
>> was installed via pacman, it installed icu64 in addition to the icu61 that
>> was already installed by the gnucash script.  I was able to remove icu64
>> and clear out the entire build and inst directories and try again.  It
>> built without errors at that point and then the first time I ran, it
>> crashed.  I had to do a glib-compile-schemas in order for it to run at that
>> point.  (I'm just documenting manual interactions in case the scripts
>> should be updated some for others).
>> 
>> Thanks all for your help so far.  Now onto trying to debug the chart hang
>> problem.
>> 
> Thanks for the feedback.
> 
> How exactly did you run gnucash ?
> 
> I think the whole windows build system is set up to create a Windows 
> installer 
> for the gnucash package and run gnucash after this installer has run.
> 
> On the other hand, if simply running the glib-compile-schemas on the end 
> result of the build script helps you run it without invoking the Windows 
> installer, that's a worthwile bonus.
> 
> I *thought* we did run this while building, but a quick scan of the build 
> scripts suggest it's only run while bundling gnucash. I wonder why that is. 
> Perhaps John remembers.

Because everything else that uses GSettings is built by MinGW, because there's 
no need for GSettings during the build process and glib-compile-schemas is 
comprehensive so running it once at the end does the job.

IIRC we disabled compiling the schemas at build time because it set up the 
paths for the build directory and so the compiled schemas failed after the 
install step.

As for the build system set up, build_package.ps1 does indeed build a setup.exe 
for distribution and even uploads it to the distribution server if provided 
with an upload URI. For other purposes the build system does require a bit of 
manual intervention. That's equally true on Unix including MacOS.

Regards,
John Ralls
  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-24 Thread John Ralls



> On Aug 23, 2019, at 11:28 PM, Geert Janssens  
> wrote:
> 
> Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash-
> devel:
>> I have finally had time to sit down and try again.  When libxml development
>> was installed via pacman, it installed icu64 in addition to the icu61 that
>> was already installed by the gnucash script.  I was able to remove icu64
>> and clear out the entire build and inst directories and try again.  It
>> built without errors at that point and then the first time I ran, it
>> crashed.  I had to do a glib-compile-schemas in order for it to run at that
>> point.  (I'm just documenting manual interactions in case the scripts
>> should be updated some for others).
>> 
>> Thanks all for your help so far.  Now onto trying to debug the chart hang
>> problem.
>> 
> Thanks for the feedback.
> 
> How exactly did you run gnucash ?
> 
> I think the whole windows build system is set up to create a Windows 
> installer 
> for the gnucash package and run gnucash after this installer has run.
> 
> On the other hand, if simply running the glib-compile-schemas on the end 
> result of the build script helps you run it without invoking the Windows 
> installer, that's a worthwile bonus.
> 
> I *thought* we did run this while building, but a quick scan of the build 
> scripts suggest it's only run while bundling gnucash. I wonder why that is. 
> Perhaps John remembers.

Because everything else that uses GSettings is built by MinGW, because there's 
no need for GSettings during the build process and glib-compile-schemas is 
comprehensive so running it once at the end does the job.

IIRC we disabled compiling the schemas at build time because it set up the 
paths for the build directory and so the compiled schemas failed after the 
install step.

As for the build system set up, build_package.ps1 does indeed build a setup.exe 
for distribution and even uploads it to the distribution server if provided 
with an upload URI. For other purposes the build system does require a bit of 
manual intervention. That's equally true on Unix including MacOS.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-24 Thread Geert Janssens
Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash-
devel:
> I have finally had time to sit down and try again.  When libxml development
> was installed via pacman, it installed icu64 in addition to the icu61 that
> was already installed by the gnucash script.  I was able to remove icu64
> and clear out the entire build and inst directories and try again.  It
> built without errors at that point and then the first time I ran, it
> crashed.  I had to do a glib-compile-schemas in order for it to run at that
> point.  (I'm just documenting manual interactions in case the scripts
> should be updated some for others).
> 
> Thanks all for your help so far.  Now onto trying to debug the chart hang
> problem.
> 
Thanks for the feedback.

How exactly did you run gnucash ?

I think the whole windows build system is set up to create a Windows installer 
for the gnucash package and run gnucash after this installer has run.

On the other hand, if simply running the glib-compile-schemas on the end 
result of the build script helps you run it without invoking the Windows 
installer, that's a worthwile bonus.

I *thought* we did run this while building, but a quick scan of the build 
scripts suggest it's only run while bundling gnucash. I wonder why that is. 
Perhaps John remembers.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-23 Thread Matthew Forbis via gnucash-devel
I have finally had time to sit down and try again.  When libxml development was 
installed via pacman, it installed icu64 in addition to the icu61 that was 
already installed by the gnucash script.  I was able to remove icu64 and clear 
out the entire build and inst directories and try again.  It built without 
errors at that point and then the first time I ran, it crashed.  I had to do a 
glib-compile-schemas in order for it to run at that point.  (I'm just 
documenting manual interactions in case the scripts should be updated some for 
others).

Thanks all for your help so far.  Now onto trying to debug the chart hang 
problem.

Thanks,
Matt





On Friday, August 16, 2019, 7:53:09 AM CDT, Matthew Forbis 
 wrote: 




Yes I have that commit on my system and had a clean build directory for gnucash 
prior to starting the compile.

Thanks,
Matt




On Thursday, August 15, 2019, 10:21:50 PM CDT, John Ralls  
wrote: 





I had a similar build failure on MacOS a few hours ago and pushed 
https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573
 to fix it. Did your build have that commit?

Regards,
John Ralls


> On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel 
>  wrote:
> 
> Hi responding to myself:
> 
> First, forgot plain text in the first email, so I fixed the formatting in the 
> original below to make it easier to read.
> Second, my system has both icu 61 which is the one explicitly required for 
> webkit as well as has icu 64 which was installed as part of the libxml2 
> library.  When I do a pkg-config, it finds the version 61 one.  I suspect 
> this might be related to my problem, but I'm not experienced enough as a 
> programmer to figure out how to solve it.
> 
> Thanks,
> Matt
> 
> 
> 
> On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via 
> gnucash-devel  wrote: 
> 
> 
> Hi All,
> I have recently worked on building GNUCash on windows to try to debug a 
> problem I've been having with my reports.  I found a few things that look 
> like the script might need to be updated for (or I had something wrong in my 
> procedure).
> 
> 1.  I had to install some packages through pacman manually:
> openssl-devel - this seemed to keep python's hashlib from working correctly 
> and not able to go very in the build process (I didn't start keeping notes 
> right at the beginning).
> mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I 
> had to install it to continue. (I think I had to use this format as well to 
> install)
> glib2-devel - Required for gnucash.
> libxml2-devel - Required for gnucash
> libxslt-devel - Required for gnucash
> 
> 2.  When I got to webkitgtk3, I noticed it hadn't installed during the setup 
> powershell script.  This failed due to a missing angleproject package.  This 
> was not available in pacman anymore, so I ended up modifying 
> setup-mingw64.ps1 to add this to the install and re-ran it and it appears to 
> have installed correctly.
> 
> But, that brings me to now where I'm stuck.  I am getting the following error 
> when building:
> [ 42%] Linking CXX shared library 
> ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function 
> `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214:
>  undefined reference to 
> `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: 
> undefined reference to 
> `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: 
> undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) 
> const'collect2.exe: error: ld returned 1 exit status
> 
> Any hints as to how to debug this one?
> 
> Thanks,
> Matt
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-16 Thread Matthew Forbis via gnucash-devel
 Yes I have that commit on my system and had a clean build directory for 
gnucash prior to starting the compile.
Thanks,Matt
On Thursday, August 15, 2019, 10:21:50 PM CDT, John Ralls 
 wrote:  
 
 I had a similar build failure on MacOS a few hours ago and pushed 
https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573
 to fix it. Did your build have that commit?

Regards,
John Ralls


> On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel 
>  wrote:
> 
> Hi responding to myself:
> 
> First, forgot plain text in the first email, so I fixed the formatting in the 
> original below to make it easier to read.
> Second, my system has both icu 61 which is the one explicitly required for 
> webkit as well as has icu 64 which was installed as part of the libxml2 
> library.  When I do a pkg-config, it finds the version 61 one.  I suspect 
> this might be related to my problem, but I'm not experienced enough as a 
> programmer to figure out how to solve it.
> 
> Thanks,
> Matt
> 
> 
> 
> On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via 
> gnucash-devel  wrote: 
> 
> 
> Hi All,
> I have recently worked on building GNUCash on windows to try to debug a 
> problem I've been having with my reports.  I found a few things that look 
> like the script might need to be updated for (or I had something wrong in my 
> procedure).
> 
> 1.  I had to install some packages through pacman manually:
> openssl-devel - this seemed to keep python's hashlib from working correctly 
> and not able to go very in the build process (I didn't start keeping notes 
> right at the beginning).
> mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I 
> had to install it to continue. (I think I had to use this format as well to 
> install)
> glib2-devel - Required for gnucash.
> libxml2-devel - Required for gnucash
> libxslt-devel - Required for gnucash
> 
> 2.  When I got to webkitgtk3, I noticed it hadn't installed during the setup 
> powershell script.  This failed due to a missing angleproject package.  This 
> was not available in pacman anymore, so I ended up modifying 
> setup-mingw64.ps1 to add this to the install and re-ran it and it appears to 
> have installed correctly.
> 
> But, that brings me to now where I'm stuck.  I am getting the following error 
> when building:
> [ 42%] Linking CXX shared library 
> ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function 
> `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214:
>  undefined reference to 
> `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: 
> undefined reference to 
> `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: 
> undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) 
> const'collect2.exe: error: ld returned 1 exit status
> 
> Any hints as to how to debug this one?
> 
> Thanks,
> Matt
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-15 Thread John Ralls
I had a similar build failure on MacOS a few hours ago and pushed 
https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573
 to fix it. Did your build have that commit?

Regards,
John Ralls


> On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel 
>  wrote:
> 
> Hi responding to myself:
> 
> First, forgot plain text in the first email, so I fixed the formatting in the 
> original below to make it easier to read.
> Second, my system has both icu 61 which is the one explicitly required for 
> webkit as well as has icu 64 which was installed as part of the libxml2 
> library.  When I do a pkg-config, it finds the version 61 one.  I suspect 
> this might be related to my problem, but I'm not experienced enough as a 
> programmer to figure out how to solve it.
> 
> Thanks,
> Matt
> 
> 
> 
> On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via 
> gnucash-devel  wrote: 
> 
> 
> Hi All,
> I have recently worked on building GNUCash on windows to try to debug a 
> problem I've been having with my reports.  I found a few things that look 
> like the script might need to be updated for (or I had something wrong in my 
> procedure).
> 
> 1.  I had to install some packages through pacman manually:
> openssl-devel - this seemed to keep python's hashlib from working correctly 
> and not able to go very in the build process (I didn't start keeping notes 
> right at the beginning).
> mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I 
> had to install it to continue. (I think I had to use this format as well to 
> install)
> glib2-devel - Required for gnucash.
> libxml2-devel - Required for gnucash
> libxslt-devel - Required for gnucash
> 
> 2.  When I got to webkitgtk3, I noticed it hadn't installed during the setup 
> powershell script.  This failed due to a missing angleproject package.  This 
> was not available in pacman anymore, so I ended up modifying 
> setup-mingw64.ps1 to add this to the install and re-ran it and it appears to 
> have installed correctly.
> 
> But, that brings me to now where I'm stuck.  I am getting the following error 
> when building:
> [ 42%] Linking CXX shared library 
> ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function 
> `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214:
>  undefined reference to 
> `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: 
> undefined reference to 
> `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
>  C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: 
> undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) 
> const'collect2.exe: error: ld returned 1 exit status
> 
> Any hints as to how to debug this one?
> 
> Thanks,
> Matt
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Building on Windows

2019-08-15 Thread Matthew Forbis via gnucash-devel
Hi responding to myself:

First, forgot plain text in the first email, so I fixed the formatting in the 
original below to make it easier to read.
Second, my system has both icu 61 which is the one explicitly required for 
webkit as well as has icu 64 which was installed as part of the libxml2 
library.  When I do a pkg-config, it finds the version 61 one.  I suspect this 
might be related to my problem, but I'm not experienced enough as a programmer 
to figure out how to solve it.

Thanks,
Matt



On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via gnucash-devel 
 wrote: 


Hi All,
I have recently worked on building GNUCash on windows to try to debug a problem 
I've been having with my reports.  I found a few things that look like the 
script might need to be updated for (or I had something wrong in my procedure).

1.  I had to install some packages through pacman manually:
openssl-devel - this seemed to keep python's hashlib from working correctly and 
not able to go very in the build process (I didn't start keeping notes right at 
the beginning).
mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I had 
to install it to continue. (I think I had to use this format as well to install)
glib2-devel - Required for gnucash.
libxml2-devel - Required for gnucash
libxslt-devel - Required for gnucash

2.  When I got to webkitgtk3, I noticed it hadn't installed during the setup 
powershell script.  This failed due to a missing angleproject package.  This 
was not available in pacman anymore, so I ended up modifying setup-mingw64.ps1 
to add this to the install and re-ran it and it appears to have installed 
correctly.

But, that brings me to now where I'm stuck.  I am getting the following error 
when building:
[ 42%] Linking CXX shared library 
../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
 CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function 
`gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214:
 undefined reference to 
`icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
 C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: 
undefined reference to 
`u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
 C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: 
undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) 
const'collect2.exe: error: ld returned 1 exit status

Any hints as to how to debug this one?

Thanks,
Matt
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel