> > 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? 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? 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? >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. There have been concerns regarding the MS runtime/mingw (excetions/crashes/interop problems) and speaks to the very real problem that even if you can get it to build it may not be stable (yes one could argue the alternative stability of MS run-time in general). For instance does: "Program: C:\Program Files (x86)\gnucash\bin\gnucash.exe This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information" sound familiar? Ironic how this window appeared literally while I was writing this... no joke. At some point if I recall correctly GTK folks even wanted to build their own build tool as apposed to using CMake... I am still waiting for that to happen, heck may even help support it as CMake has it's deficiencies some through core design and others due to it's evolution. 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. The page at https://www.gtk.org/download/windows.php https://wiki.gnome.org/ Projects/GTK+/Win32/MSVCCompilationOfGTKStack still makes me wonder if GTK knows what a superbuild is. Then there is Nacho's blog https://blogs.gnome.org/nacho/2015/02/19/building-gtk-3-with-msvc-2013/ which is MSVC 2013 related which is all fine and all until say 2015, 2017 etc when VS build tools ?evolve?. I do find it interesting that I have to read about how to build a opensource project from someone's dated blog, not only that, but if seems the "official" windows how-to-build link form GTK's web site... stellar. CMake being a metabuild tool can generate vs projects for the tools is supports VS/MSbuild, cygwin, MSys/MinGW etc and for the various versions 2008, 2010, 2012, 2013, 2015, 2017 etc. If mingw is an abs requirement I would be interested to go through this script to port functionality to CMake to setup/configure build environment. This would require a 3 stage cmake 1) set up msys build environment much as the script does and 2) download and build dependencies in a superbuild 3) build GnuCash. Possibly combining 2 and 3 into one step. This could remove the gnucash-on-windows.git and git download dep. With exsiting MSys install or MSBuild it could possibly be a 1 stage CMake superbuild. > P.S.: John's thoughts are worth considering still. Developing gnucash on > Windows does add some complexity. And for the 2.6 series it's even > cumbersome. > I think I am on the same page as to the "complexity" (see above). Is it GTK/glib and gtk dep related or does gnucash have similar msys/mingw deps? > The scripts for 2.7 and the upcoming 2.8 will help improve the situation. > How? > However depending on your skill and specific goals it's still worth > considering to set up a virtual machine running linux instead. > Yes I can with my VMs build to a remote share for windows testing. There are references to setting up a build server etc. Where is recipe for this? > More generally though I would also love to see people on Windows pick up > gnucash development (on Windows) and in particular help improve the Windows > situation where possible. Hard to when people can't get it to compile due to build spec and deps. > I'm thinking of Windows specific bugs, or > improvements to the build system to reduce the complexity gap between > developing on Windows and linux. Not sure what could be done for the latter > but one can hope, right ;) > Hmmm CMake build for Linux AND Windows possibly? If community(frustrated devs - read me) could get GTK and their package dep devs to use/support it. > If this interests you and you think you can, you're certainly welcome to > contribute in that area too. > I wanted to see how hard it would be to implement multi select in GnuCash, a feature IMO is long overdue. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
