Re: Gnucash reports using php and mysql
On Thu, 29 Dec 2011 10:44:31 +0100, Gour wrote: > On Wed, 21 Dec 2011 10:10:39 -0500 > Donald Allen wrote: > >> My motivation was the same as yours -- I could not get what I wanted >> from the built-in reports and I felt that the cost of trying to learn >> to work within gnucash (in spite of the fact that I am a *very* >> experienced Scheme programmer) was higher than the approach I took. > > Huh...this does not sound optimistic for potential GC users wanting to > customize their invoices/reports... > > Is there any plan to improve reporting system in 2.6 or we cannot expect > anything before 3.0? > >> I'd suggest >> having a look at an interesting thread, "Scripting API", on >> gnucash-devel started by Hendrik Boom in November. It discusses similar >> issues and the subject of the fairly new python bindings capability >> comes up, something I have not investigated myself (only because I >> already have something that serves my purpose, developed before the >> python bindings capability became available) but is probably worth >> looking at if you are actively developing reports for yourself. It's still on my personal TODO list, but family and other matters have severely diverted me from writing the necessary documentation, and possibly any code the documentation will suggest to me as necessary. I still intend to get back to this. I still thiink that the primary problem with the report-writing tools is not that they are unusable, but that no one knows how to use them. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
On Dec 29, 2011, at 2:20 PM, Christian Stimming wrote: > Am Donnerstag, 29. Dezember 2011, 14:00:51 schrieb John Ralls: >> On Dec 27, 2011, at 10:09 PM, John Ralls wrote: >>> It's still not quite ready for release: Gnucash isn't noticing that AQB >>> is present. >> Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs >> a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) >> and we were relying on WebKit to provide them -- but it only provides an >> older version of libstdc++-1. > > Very interesting. Now, libktoblzcheck isn't anything miraculous - it's just a > C++ library that we build ourselves. Apparently once we do this, the > libstdc++ > of the compiler needs to be present but hasn't been so far. > > This change is most probably also needed in trunk, isn't it? It wouldn't matter whether we built it or got a binary from somewhere: If it links against libstdc++, it has to have it. C++ library symbols are "mangled" in a compiler-specific way, so it's not possible to link a program made with one compiler against a library made with another. But that wasn't the problem here: The libstdc++-6 that WekKit provided didn't define a symbol that ktoblzcheck wanted (__gxx_personality_v0), but there are a couple of dozen others that it was perfectly happy with. That indicates a libstdc++-6 version problem rather than a wrong compiler problem. It looks to me from the symbols imported from libgcc_s_dw2-1 (Unwind_resume, _deregister_frame_info, _moddi3, and _register_frame_info) that it has to do with debugging, so we might be able to get rid of that dependency by changing CFLAGS. I don't know if it needs changing in trunk. AQB works there, right? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.
Am Donnerstag, 29. Dezember 2011, 14:00:51 schrieb John Ralls: > On Dec 27, 2011, at 10:09 PM, John Ralls wrote: > > It's still not quite ready for release: Gnucash isn't noticing that AQB > > is present. > Which turned out to be more WebKit contamination, sort of. Ktoblzcheck needs > a couple of libraries from mingw (libstdc++-6.dll and libgcc_s_dw2-1.dll) > and we were relying on WebKit to provide them -- but it only provides an > older version of libstdc++-1. Very interesting. Now, libktoblzcheck isn't anything miraculous - it's just a C++ library that we build ourselves. Apparently once we do this, the libstdc++ of the compiler needs to be present but hasn't been so far. This change is most probably also needed in trunk, isn't it? Thank you very much! Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release
On Dec 29, 2011, at 12:24 PM, Christian Stimming wrote: > Am Mittwoch, 28. Dezember 2011, 18:16:48 schrieb John Ralls: >> A release plan isn't a "list of features" to "get enough reasons" for a >> 2.6.0 release. It's a list of features and existing bugs, whether >> implemented or not, that the project team agrees should be what's going to >> be in the 2.6.0 release. It guides the testers who use the development >> (2.5.x) releases, so that they know what to try out, and to write bugs >> against. > > Ok, let my re-phrase my original proposal, like so: > > Over the past months, several very useful features for small business usage > have been added to trunk. I'd like to get those features out in the stable > releases so that users who are asking for this can get them through their > default distro package, which implies those features need to appear in a > stable release series. > > Here's an (incomplete) list of new features for small business users which is > now available in trunk but not in 2.4: > > * Customer / Vendor overview pages > * Print to PDF for reports and invoices by a single button click > * Allow "Filter By" settings to be saved and re-used > * Customer overview reports > * Line chart report for Net Worth (Bug #664862) > * Re-assign existing transactions as payments > * Duplicate invoices > * Easier invoice / bill handling: Post, Print, or Duplicate multiple items > directly from the search result list > * Better invoice printing setup: Choose the default invoice report for > printing in the preferences > * Change the ordering of invoice entries by up/down buttons in the invoice > window > > * and last but not least Geert has ongoing work to include Credit Notes > > I propose to start a new 2.5.0 / 2.6.0 release series in order to make those > "small business user" improvements available in a stable release. As already > discussed in length, there haven't been that much significant changes in > gnucash apart from these features which might seem minor to all users who > don't happen to use gnucash for running a business. On the upside, this means > trunk in itself isn't that much unstable right now, which means we will > probably get a 2.6.0 stable release ready with only very few unstable 2.5.x > releases on the way. Because of this, the extra work to get trunk into shape > for another stable branch is probably only a small distraction from longer- > term work that will continue on trunk. > >> I doubt that either Gtk3 or the engine cleanup will be done in another year >> unless a lot of help shows up. Going through a development release series >> while continuing that work in trunk will push both further out: Time spent >> getting a release polished up is time not spent on longer-term projects. >> >> By the way, the time between 2.2.0 and 2.4.0 was 42 months (July 2007 to >> December 2010); it was 22 months between releasing 2.2.0 and the first 2.3 >> release (May 2009). What's special about a year? > > Point taken. My proposal is not based on particular time frames, but rather > on > making this collection of small business improvements available in a stable > release, and do so in the near future (i.e. within the next 2-4 months). > > Other proposals / comments? Thank you. That's much better; perhaps we can turn it into a wiki page to point testers at. Are there unit tests for all of those features? I'll spend some more time chasing down edits that aren't immediately committed, so that the SQL backend is sure to work properly (and also add automated tests for that to setters). Is it feasible to remove Guile 1.6 support (by fixing the deprecation warnings with Guile 1.8)? Will that be sufficient to make Guile 2.0 work? (I'm willing to do the work.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Git Migration: github with svn access
On Dec 29, 2011, at 11:46 AM, Christian Stimming wrote: > Am Donnerstag, 29. Dezember 2011, 09:47:35 schrieb John Ralls: ISTM it would be better to have the release script look at the SHA reference in the tag using git rather than to depend upon Github's subversion gateway. > > Absolutely. After thinking about this for a bit, I think retrieving the > various branches via git and checking for existence of new tags is clearly > much more easy using git, compared to using svn. However, it means we must re- > write those parts of the build scripts. > >>> Last time I checked (a few minutes ago), git support on Windows was >>> still in beta, at least the project I found: >>> http://code.google.com/p/msysgit/ >>> >>> Perhaps there's another one ? >> >> On the one hand, I wouldn't worry about that too much: It looks like it's >> always been "beta". What's more, the beta-ness likely has more to do with >> the GUI, and we're not really interested in that, just in some of the basic >> git commands. >> >> On the other hand, it installs a complete MinGW/MSys for its private use, so >> I'm looking into building git from source in our existing environment. > > I've been using git on windows for years in my daily work by now. The one > from > http://code.google.com/p/msysgit/downloads/list?can=3 is indeed the > "official" > one if you want a git (cmdline) executable on windows. I think it's pointless > to try to build a smaller git package yourself. Just use the git.exe that > comes with that package and that's it. In my work computer, I have a msys > installation that I use for my normal work, but the git.exe comes from that > very package which additionally has its own msys installation. Apart from the > large download volume I didn't notice any problems in this setup. > > If I have some time during the next days, I'll look into porting the SVN- > dependencies in our build scripts to using git. Also, I don't think it's > necessary to distinguish tags that should trigger a build from those which > don't - we can just as well have *each* tag trigger a rebuild on its own. The > build server "just" needs a list of tag and SHA1. Good to know. It doesn't look like I'd be able to get git built in our environment without some surgery on it... compat/regex won't build. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21789 - gnucash/trunk/packaging/win32 - [Win32 build] Enable libxslt to be built in a cross-compile environment.
Am Donnerstag, 29. Dezember 2011, 21:27:45 schrieb Geert Janssens:
> Op donderdag 29 december 2011 14:50:56 schreef Christian Stimming:
> > Author: cstim
> > Date: 2011-12-29 14:50:56 -0500 (Thu, 29 Dec 2011)
> > New Revision: 21789
> > Trac: http://svn.gnucash.org/trac/changeset/21789
> >
> > Modified:
> >gnucash/trunk/packaging/win32/install-impl.sh
> >
> > Log:
> > [Win32 build] Enable libxslt to be built in a cross-compile environment.
> >
> > Modified: gnucash/trunk/packaging/win32/install-impl.sh
> > ===
> > --- gnucash/trunk/packaging/win32/install-impl.sh 2011-12-29 19:50:40
> > UTC
> > (rev 21788) +++ gnucash/trunk/packaging/win32/install-impl.sh
2011-12-29
> > 19:50:56 UTC (rev 21789) @@ -1139,9 +1139,15 @@
> >
> > then
> >
> > echo "libxslt already installed in $_LIBXSLT_UDIR.
> > skipping."
> >
> > else
> >
> > -[ "$CROSS_COMPILE" = "yes" ] && die "xsltproc unavailable"
> > -#wget_unpacked ${LIBXSLT_ICONV_URL} ${DOWNLOAD_DIR}
> > ${LIBXSLT_DIR} -#wget_unpacked ${LIBXSLT_ZLIB_URL}
> > ${DOWNLOAD_DIR} ${LIBXSLT_DIR} +if [ "$CROSS_COMPILE" = "yes"
> > ]; then
> > +
> > _MORE_CPPFLAGS="-I${_LIBXSLT_UDIR}/iconv-1.9.2.win32/include" +
> >_MORE_LDFLAGS="-L${_LIBXSLT_UDIR}/lib"
> > +wget_unpacked ${LIBXSLT_ICONV_URL} ${DOWNLOAD_DIR}
> > ${LIBXSLT_DIR} +wget_unpacked ${LIBXSLT_ZLIB_URL}
> > ${DOWNLOAD_DIR} ${LIBXSLT_DIR} +else
> > +_MORE_CPPFLAGS=""
> > +_MORE_LDFLAGS=""
> > +fi
> >
> > wget_unpacked $LIBXSLT_SRC_URL $DOWNLOAD_DIR $TMP_DIR
> > assert_one_dir $TMP_UDIR/libxslt-*
> >
> > @@ -1150,7 +1156,7 @@
> >
> > ./configure ${HOST_XCOMPILE} \
> >
> > --prefix=${_LIBXSLT_UDIR} \
> > --with-python=no \
> >
> > ---with-libxml-prefix=${_GNOME_UDIR}
> > CPPFLAGS="${GNUTLS_CPPFLAGS}" LDFLAGS="${GNUTLS_LDFLAGS}" +
> > --with-libxml-prefix=${_GNOME_UDIR} CPPFLAGS="${GNUTLS_CPPFLAGS}
> > ${_MORE_CPPFLAGS}" LDFLAGS="${GNUTLS_LDFLAGS} ${_MORE_LDFLAGS}" make
> >
> > make install
> >
> > qpopd
>
> Your commit went in just ahead of mine regarding libxslt building.
>
> Just for your information, libxslt doesn't build natively either due to a
> missing iconv.h include file. I fixed the build by adding GNOME_CPPFLAGS and
> GNOME_LDFLAGS. I haven't been able to test it so yet as I'm waiting for a
> dist.sh run after some fixes in there.
>
> After sending in my commit (which adds your new parameters at the end) I
> wondered if it would not be sufficient to use the GNOME_CPPFLAGS and
> GNOME_LDFLAGS for cross-compiling as well ? Or do you think you explicitly
> need to install your own zlib and iconv libraries for libxslt ?
No, I think you were right and I was wrong. The old separate zlib and iconv
libraries must be a leftover from when libxslt was downloaded in a pre-
compiled version. However, in our resulting gnucash executable there must be
only one version of zlib and iconv, and all other linked-in libraries must
have been linking against this very version instead of multiple different
versions. Hence, the separate DLL was a bad choice to begin with. I've removed
my flags again.
Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21789 - gnucash/trunk/packaging/win32 - [Win32 build] Enable libxslt to be built in a cross-compile environment.
Op donderdag 29 december 2011 21:27:45 schreef Geert Janssens:
> Op donderdag 29 december 2011 14:50:56 schreef Christian Stimming:
> > Author: cstim
> > Date: 2011-12-29 14:50:56 -0500 (Thu, 29 Dec 2011)
> > New Revision: 21789
> > Trac: http://svn.gnucash.org/trac/changeset/21789
> >
> > Modified:
> >gnucash/trunk/packaging/win32/install-impl.sh
> >
> > Log:
> > [Win32 build] Enable libxslt to be built in a cross-compile environment.
> >
> > Modified: gnucash/trunk/packaging/win32/install-impl.sh
> > ===
> > --- gnucash/trunk/packaging/win32/install-impl.sh 2011-12-29 19:50:40
> > UTC
> > (rev 21788) +++ gnucash/trunk/packaging/win32/install-impl.sh
> > 2011-12-29
> > 19:50:56 UTC (rev 21789) @@ -1139,9 +1139,15 @@
> >
> > then
> >
> > echo "libxslt already installed in $_LIBXSLT_UDIR.
> > skipping."
> >
> > else
> >
> > -[ "$CROSS_COMPILE" = "yes" ] && die "xsltproc unavailable"
> > -#wget_unpacked ${LIBXSLT_ICONV_URL} ${DOWNLOAD_DIR}
> > ${LIBXSLT_DIR} -#wget_unpacked ${LIBXSLT_ZLIB_URL}
> > ${DOWNLOAD_DIR} ${LIBXSLT_DIR} +if [ "$CROSS_COMPILE" = "yes"
> > ]; then
> > +
> > _MORE_CPPFLAGS="-I${_LIBXSLT_UDIR}/iconv-1.9.2.win32/include" +
> >_MORE_LDFLAGS="-L${_LIBXSLT_UDIR}/lib"
> > +wget_unpacked ${LIBXSLT_ICONV_URL} ${DOWNLOAD_DIR}
> > ${LIBXSLT_DIR} +wget_unpacked ${LIBXSLT_ZLIB_URL}
> > ${DOWNLOAD_DIR} ${LIBXSLT_DIR} +else
> > +_MORE_CPPFLAGS=""
> > +_MORE_LDFLAGS=""
> > +fi
> >
> > wget_unpacked $LIBXSLT_SRC_URL $DOWNLOAD_DIR $TMP_DIR
> > assert_one_dir $TMP_UDIR/libxslt-*
> >
> > @@ -1150,7 +1156,7 @@
> >
> > ./configure ${HOST_XCOMPILE} \
> >
> > --prefix=${_LIBXSLT_UDIR} \
> > --with-python=no \
> >
> > ---with-libxml-prefix=${_GNOME_UDIR}
> > CPPFLAGS="${GNUTLS_CPPFLAGS}" LDFLAGS="${GNUTLS_LDFLAGS}" +
> > --with-libxml-prefix=${_GNOME_UDIR} CPPFLAGS="${GNUTLS_CPPFLAGS}
> > ${_MORE_CPPFLAGS}" LDFLAGS="${GNUTLS_LDFLAGS} ${_MORE_LDFLAGS}" make
> >
> > make install
> >
> > qpopd
>
> Your commit went in just ahead of mine regarding libxslt building.
>
> Just for your information, libxslt doesn't build natively either due to a
> missing iconv.h include file. I fixed the build by adding GNOME_CPPFLAGS and
> GNOME_LDFLAGS. I haven't been able to test it so yet as I'm waiting for a
> dist.sh run after some fixes in there.
>
> After sending in my commit (which adds your new parameters at the end) I
> wondered if it would not be sufficient to use the GNOME_CPPFLAGS and
> GNOME_LDFLAGS for cross-compiling as well ? Or do you think you explicitly
> need to install your own zlib and iconv libraries for libxslt ?
Hmm, no, it didn't work. The build works fine, but I can't open compressed
files (I seem to remember a closed bugreport about that, I'll have to look it
up).
Unfortunately my time is up today. I'll see if I can fix it properly tomorrow
(if noone beats me to it ;)
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r21789 - gnucash/trunk/packaging/win32 - [Win32 build] Enable libxslt to be built in a cross-compile environment.
Op donderdag 29 december 2011 14:50:56 schreef Christian Stimming:
> Author: cstim
> Date: 2011-12-29 14:50:56 -0500 (Thu, 29 Dec 2011)
> New Revision: 21789
> Trac: http://svn.gnucash.org/trac/changeset/21789
>
> Modified:
>gnucash/trunk/packaging/win32/install-impl.sh
> Log:
> [Win32 build] Enable libxslt to be built in a cross-compile environment.
>
> Modified: gnucash/trunk/packaging/win32/install-impl.sh
> ===
> --- gnucash/trunk/packaging/win32/install-impl.sh 2011-12-29 19:50:40 UTC
> (rev 21788) +++ gnucash/trunk/packaging/win32/install-impl.sh 2011-12-29
> 19:50:56 UTC (rev 21789) @@ -1139,9 +1139,15 @@
> then
> echo "libxslt already installed in $_LIBXSLT_UDIR. skipping."
> else
> -[ "$CROSS_COMPILE" = "yes" ] && die "xsltproc unavailable"
> -#wget_unpacked ${LIBXSLT_ICONV_URL} ${DOWNLOAD_DIR} ${LIBXSLT_DIR}
> -#wget_unpacked ${LIBXSLT_ZLIB_URL} ${DOWNLOAD_DIR} ${LIBXSLT_DIR}
> +if [ "$CROSS_COMPILE" = "yes" ]; then
> +_MORE_CPPFLAGS="-I${_LIBXSLT_UDIR}/iconv-1.9.2.win32/include"
> +_MORE_LDFLAGS="-L${_LIBXSLT_UDIR}/lib"
> +wget_unpacked ${LIBXSLT_ICONV_URL} ${DOWNLOAD_DIR}
> ${LIBXSLT_DIR} +wget_unpacked ${LIBXSLT_ZLIB_URL}
> ${DOWNLOAD_DIR} ${LIBXSLT_DIR} +else
> +_MORE_CPPFLAGS=""
> +_MORE_LDFLAGS=""
> +fi
>
> wget_unpacked $LIBXSLT_SRC_URL $DOWNLOAD_DIR $TMP_DIR
> assert_one_dir $TMP_UDIR/libxslt-*
> @@ -1150,7 +1156,7 @@
> ./configure ${HOST_XCOMPILE} \
> --prefix=${_LIBXSLT_UDIR} \
> --with-python=no \
> ---with-libxml-prefix=${_GNOME_UDIR}
> CPPFLAGS="${GNUTLS_CPPFLAGS}" LDFLAGS="${GNUTLS_LDFLAGS}" +
> --with-libxml-prefix=${_GNOME_UDIR} CPPFLAGS="${GNUTLS_CPPFLAGS}
> ${_MORE_CPPFLAGS}" LDFLAGS="${GNUTLS_LDFLAGS} ${_MORE_LDFLAGS}" make
> make install
> qpopd
>
Your commit went in just ahead of mine regarding libxslt building.
Just for your information, libxslt doesn't build natively either due to a
missing iconv.h include file. I fixed the build by adding GNOME_CPPFLAGS and
GNOME_LDFLAGS. I haven't been able to test it so yet as I'm waiting for a
dist.sh run after some fixes in there.
After sending in my commit (which adds your new parameters at the end) I
wondered if it would not be sufficient to use the GNOME_CPPFLAGS and
GNOME_LDFLAGS for cross-compiling as well ? Or do you think you explicitly
need to install your own zlib and iconv libraries for libxslt ?
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release
Am Mittwoch, 28. Dezember 2011, 18:16:48 schrieb John Ralls: > A release plan isn't a "list of features" to "get enough reasons" for a > 2.6.0 release. It's a list of features and existing bugs, whether > implemented or not, that the project team agrees should be what's going to > be in the 2.6.0 release. It guides the testers who use the development > (2.5.x) releases, so that they know what to try out, and to write bugs > against. Ok, let my re-phrase my original proposal, like so: Over the past months, several very useful features for small business usage have been added to trunk. I'd like to get those features out in the stable releases so that users who are asking for this can get them through their default distro package, which implies those features need to appear in a stable release series. Here's an (incomplete) list of new features for small business users which is now available in trunk but not in 2.4: * Customer / Vendor overview pages * Print to PDF for reports and invoices by a single button click * Allow "Filter By" settings to be saved and re-used * Customer overview reports * Line chart report for Net Worth (Bug #664862) * Re-assign existing transactions as payments * Duplicate invoices * Easier invoice / bill handling: Post, Print, or Duplicate multiple items directly from the search result list * Better invoice printing setup: Choose the default invoice report for printing in the preferences * Change the ordering of invoice entries by up/down buttons in the invoice window * and last but not least Geert has ongoing work to include Credit Notes I propose to start a new 2.5.0 / 2.6.0 release series in order to make those "small business user" improvements available in a stable release. As already discussed in length, there haven't been that much significant changes in gnucash apart from these features which might seem minor to all users who don't happen to use gnucash for running a business. On the upside, this means trunk in itself isn't that much unstable right now, which means we will probably get a 2.6.0 stable release ready with only very few unstable 2.5.x releases on the way. Because of this, the extra work to get trunk into shape for another stable branch is probably only a small distraction from longer- term work that will continue on trunk. > I doubt that either Gtk3 or the engine cleanup will be done in another year > unless a lot of help shows up. Going through a development release series > while continuing that work in trunk will push both further out: Time spent > getting a release polished up is time not spent on longer-term projects. > > By the way, the time between 2.2.0 and 2.4.0 was 42 months (July 2007 to > December 2010); it was 22 months between releasing 2.2.0 and the first 2.3 > release (May 2009). What's special about a year? Point taken. My proposal is not based on particular time frames, but rather on making this collection of small business improvements available in a stable release, and do so in the near future (i.e. within the next 2-4 months). Other proposals / comments? Best Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Git Migration: github with svn access
Am Donnerstag, 29. Dezember 2011, 09:47:35 schrieb John Ralls: > >> ISTM it would be better to have the release script look at the SHA > >> reference in the tag using git rather than to depend upon Github's > >> subversion gateway. Absolutely. After thinking about this for a bit, I think retrieving the various branches via git and checking for existence of new tags is clearly much more easy using git, compared to using svn. However, it means we must re- write those parts of the build scripts. > > Last time I checked (a few minutes ago), git support on Windows was > > still in beta, at least the project I found: > > http://code.google.com/p/msysgit/ > > > > Perhaps there's another one ? > > On the one hand, I wouldn't worry about that too much: It looks like it's > always been "beta". What's more, the beta-ness likely has more to do with > the GUI, and we're not really interested in that, just in some of the basic > git commands. > > On the other hand, it installs a complete MinGW/MSys for its private use, so > I'm looking into building git from source in our existing environment. I've been using git on windows for years in my daily work by now. The one from http://code.google.com/p/msysgit/downloads/list?can=3 is indeed the "official" one if you want a git (cmdline) executable on windows. I think it's pointless to try to build a smaller git package yourself. Just use the git.exe that comes with that package and that's it. In my work computer, I have a msys installation that I use for my normal work, but the git.exe comes from that very package which additionally has its own msys installation. Apart from the large download volume I didn't notice any problems in this setup. If I have some time during the next days, I'll look into porting the SVN- dependencies in our build scripts to using git. Also, I don't think it's necessary to distinguish tags that should trigger a build from those which don't - we can just as well have *each* tag trigger a rebuild on its own. The build server "just" needs a list of tag and SHA1. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Git Migration: github with svn access
On Dec 29, 2011, at 7:45 AM, Geert Janssens wrote: > Op woensdag 28 december 2011 17:08:13 schreef John Ralls: >>> Heh, don't underestimate the configuration of our Windows build server. >>> >>> It checks every night if it has to (re)build some tagged versions. It >>> does this by making a list of all tags (and their associated revision) >>> and comparing this with yesterday's list. If there is any tag/revision >>> combination that doesn't exist yet, it will rebuild this tag. >>> >>> So if the revision numbers in git don't match those in our own svn tree, >>> that means that the server will attempt to rebuild every tag that is >>> present in the tags directory (well to be precise each tag of the >>> format x.y.z). That will cause a lot of (useless) rebuilds for one >>> night.So before we switch the tag builds to use git, we better >>> 1. be very sure the git created revision numbers never change >>> 2. manually recreate the tag history file based on git's revision >>> information. >>> >>> But other than that I don't consider this a big issue. Assuming the svn >>> access github provides will be stable, and is meant to replace our own >>> internally managed svn tree, the numbering mismatch is only a temporary >>> inconvenience. >> ISTM it would be better to have the release script look at the SHA reference >> in the tag using git rather than to depend upon Github's subversion >> gateway. > I'm not opposed to this idea as such, but the whole discussion so far was > focussed on the idea of reusing the svn based automated build scripts, to > avoid the need to change everything in one go. > I've been giving my feedback with that idea in mind. > > Last time I checked (a few minutes ago), git support on Windows was still in > beta, at least the project I found: > http://code.google.com/p/msysgit/ > > Perhaps there's another one ? On the one hand, I wouldn't worry about that too much: It looks like it's always been "beta". What's more, the beta-ness likely has more to do with the GUI, and we're not really interested in that, just in some of the basic git commands. On the other hand, it installs a complete MinGW/MSys for its private use, so I'm looking into building git from source in our existing environment. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Git Migration: github with svn access
Op woensdag 28 december 2011 17:08:13 schreef John Ralls:
> > Heh, don't underestimate the configuration of our Windows build server.
> >
> > It checks every night if it has to (re)build some tagged versions. It
> > does this by making a list of all tags (and their associated revision)
> > and comparing this with yesterday's list. If there is any tag/revision
> > combination that doesn't exist yet, it will rebuild this tag.
> >
> > So if the revision numbers in git don't match those in our own svn tree,
> > that means that the server will attempt to rebuild every tag that is
> > present in the tags directory (well to be precise each tag of the
> > format x.y.z). That will cause a lot of (useless) rebuilds for one
> > night.So before we switch the tag builds to use git, we better
> > 1. be very sure the git created revision numbers never change
> > 2. manually recreate the tag history file based on git's revision
> > information.
> >
> > But other than that I don't consider this a big issue. Assuming the svn
> > access github provides will be stable, and is meant to replace our own
> > internally managed svn tree, the numbering mismatch is only a temporary
> > inconvenience.
> ISTM it would be better to have the release script look at the SHA reference
> in the tag using git rather than to depend upon Github's subversion
> gateway.
I'm not opposed to this idea as such, but the whole discussion so far was
focussed on the idea of reusing the svn based automated build scripts, to
avoid the need to change everything in one go.
I've been giving my feedback with that idea in mind.
Last time I checked (a few minutes ago), git support on Windows was still in
beta, at least the project I found:
http://code.google.com/p/msysgit/
Perhaps there's another one ?
> We probably want a bit more sophistication in the check than just
> a tag; with git people make tags (and delete) tags for all sorts of things
> besides releases... so maybe a keyword ("RELEASE"?) in the log summary, or
> a particular format for the tag ("GnuCash-Release-2.5.1"?). That would also
> save us the trouble of backfilling the history file (not that that's hard)
> since none of the existing tags are likely to meet the new criteria.
>
Agreed here.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash reports using php and mysql
On Wed, 21 Dec 2011 10:10:39 -0500 Donald Allen wrote: > My motivation was the same as yours -- I could not get what I wanted > from the built-in reports and I felt that the cost of trying to learn > to work within gnucash (in spite of the fact that I am a *very* > experienced Scheme programmer) was higher than the approach I took. Huh...this does not sound optimistic for potential GC users wanting to customize their invoices/reports... Is there any plan to improve reporting system in 2.6 or we cannot expect anything before 3.0? > I'd suggest > having a look at an interesting thread, "Scripting API", on > gnucash-devel started by Hendrik Boom in November. It discusses > similar issues and the subject of the fairly new python bindings > capability comes up, something I have not investigated myself (only > because I already have something that serves my purpose, developed > before the python bindings capability became available) but is > probably worth looking at if you are actively developing reports for > yourself. Is it now possible to use those Python bindings to more easily create/tweak reports/invocies? Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
