Re: Building unstable on Mac

[John Ralls]

Do you not know your way around autotools? Maybe it's time for a little RTFM 
[1] or you might prefer WTFV [2] (Watch the Fine Video).

Anyway, configure writes a detailed log file called config.log. You'll usually 
find useful details about configuration errors and anomalies in there. It's 
usually a good idea to find the m4 code for the test that failed, it's easier 
to read than the generated shell script in configure. The sources will be in 
configure.ac (or configure.in if the project's developers are a bit behind the 
power curve) and in a directory called variously "macros", "m4", or "m4macros". 
Libsoup uses "m4". In the case of glib-networking configure runs a little 
program, so you're be looking for the associated compiler or runtime error in 
config.log. 

Regards,
John Ralls

[1] https://autotools.io/index.html
[2] https://www.dwheeler.com/autotools/



> On Feb 1, 2018, at 3:39 PM, R. Victor Klassen  wrote:
> 
> 
> 
>> On Feb 1, 2018, at 6:31 PM, John Ralls  wrote:
>> 
>> 
>> Please remember to copy the list on all replies. 
> 
> Not intentional.
> 
>> 
>> Well, if it was installed then why isn't libsoup finding it?
> 
> I guess that’s what I’m asking.  
> Thoughts on where to look for the answer?
> 
>> 
>> Regards,
>> John Ralls
>> 
>>> On Feb 1, 2018, at 2:50 PM, R. Victor Klassen  wrote:
>>> 
>>> … or what happened that it wasn’t found?
>>> 
>>> I scrolled back (actually used find) and it was checked out, configured, 
>>> built and installed.  These appeared successful.
>>> 
>>> That was two packages before libsoup.
>>> 
 
 glib-networking is in the list of modules that should be built. What 
 happened that it wasn't?
 
 Regards,
 John Ralls
 
 
 
> On Feb 1, 2018, at 2:02 PM, R. Victor Klassen  wrote:
> 
> At some point I got the “refusing to switch to a dirty tree” error.  I 
> followed the instructions at 
> https://lists.gnucash.org/pipermail/gnucash-devel/2015-March/038616.html
> 
> [git reset --hard HEAD]
> 
> Hope that’s OK.
> 
> Next thing I remember is Boost.   That was almost impossible to check 
> out.  For whatever reason, it would abort somewhere between 2% and 92% of 
> the way through the download.   Then finally it worked.
> 
> I followed the instructions on getting Boost to compile; at the 
> instruction:
> 
> for i in `ls $PREFIX/lib/libboost*`; do install_name_tool -id $i $i; done 
> 
> I encountered a long series of errors of the form:
> 
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_atomic.a is 
> not a Mach-O file
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_chrono.a is 
> not a Mach-O file
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_container.a 
> is not a Mach-O file
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_coroutine.a 
> is not a Mach-O file
> 
> I continued, but I do wonder whether that was OK.
> 
> It did crash on the second ‘2’, as predicted, so I ran 
> 
> jhbuild build --start-at=googletest
> 
> Which picked up from there.  This failed in configure:
> 
> checking for glib-networking (glib TLS implementation)... no
> configure: error: libsoup requires glib-networking for TLS support.
> 
> If you are building a package, you can pass --disable-tls-check to
> allow building libsoup anyway (since glib-networking is not actually
> required at compile time), but you should be sure to add a runtime
> dependency on it.
> *** Error during phase configure of libsoup: ## Error running 
> ./configure --prefix /Users/gnucashdev/gnucash-unstable 
> set_more_warnings=no   *** [6/8]
> 
> I think it’s getting close...
> 
>> On Feb 1, 2018, at 10:12 AM, John Ralls  wrote:
>> 
>> You didn’t build gtk-doc and Pango requires at least the macros for it.
>> 
>> As to your question, it depends. It’s telling you on the line just below 
>> your question that pango is the seventeenth out of sixty-five packages, 
>> but it doesn’t know that some of them build in a couple of seconds and 
>> others (webkit and guile in particular) take hours.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Feb 1, 2018, at 5:55 AM, R. Victor Klassen 

Re: Building unstable on Mac

[R. Victor Klassen]

> On Feb 1, 2018, at 6:31 PM, John Ralls  wrote:
> 
> 
> Please remember to copy the list on all replies. 

Not intentional.

> 
> Well, if it was installed then why isn't libsoup finding it?

I guess that’s what I’m asking.  
Thoughts on where to look for the answer?

> 
> Regards,
> John Ralls
> 
>> On Feb 1, 2018, at 2:50 PM, R. Victor Klassen  wrote:
>> 
>> … or what happened that it wasn’t found?
>> 
>> I scrolled back (actually used find) and it was checked out, configured, 
>> built and installed.  These appeared successful.
>> 
>> That was two packages before libsoup.
>> 
>>> 
>>> glib-networking is in the list of modules that should be built. What 
>>> happened that it wasn't?
>>> 
>>> Regards,
>>> John Ralls
>>> 
>>> 
>>> 
 On Feb 1, 2018, at 2:02 PM, R. Victor Klassen  wrote:
 
 At some point I got the “refusing to switch to a dirty tree” error.  I 
 followed the instructions at 
 https://lists.gnucash.org/pipermail/gnucash-devel/2015-March/038616.html
 
 [git reset --hard HEAD]
 
 Hope that’s OK.
 
 Next thing I remember is Boost.   That was almost impossible to check out. 
  For whatever reason, it would abort somewhere between 2% and 92% of the 
 way through the download.   Then finally it worked.
 
 I followed the instructions on getting Boost to compile; at the 
 instruction:
 
 for i in `ls $PREFIX/lib/libboost*`; do install_name_tool -id $i $i; done 
 
 I encountered a long series of errors of the form:
 
 error: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_atomic.a is 
 not a Mach-O file
 error: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_chrono.a is 
 not a Mach-O file
 error: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_container.a 
 is not a Mach-O file
 error: 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_coroutine.a 
 is not a Mach-O file
 
 I continued, but I do wonder whether that was OK.
 
 It did crash on the second ‘2’, as predicted, so I ran 
 
 jhbuild build --start-at=googletest
 
 Which picked up from there.  This failed in configure:
 
 checking for glib-networking (glib TLS implementation)... no
 configure: error: libsoup requires glib-networking for TLS support.
 
 If you are building a package, you can pass --disable-tls-check to
 allow building libsoup anyway (since glib-networking is not actually
 required at compile time), but you should be sure to add a runtime
 dependency on it.
 *** Error during phase configure of libsoup: ## Error running 
 ./configure --prefix /Users/gnucashdev/gnucash-unstable 
 set_more_warnings=no   *** [6/8]
 
 I think it’s getting close...
 
> On Feb 1, 2018, at 10:12 AM, John Ralls  wrote:
> 
> You didn’t build gtk-doc and Pango requires at least the macros for it.
> 
> As to your question, it depends. It’s telling you on the line just below 
> your question that pango is the seventeenth out of sixty-five packages, 
> but it doesn’t know that some of them build in a couple of seconds and 
> others (webkit and guile in particular) take hours.
> 
> Regards,
> John Ralls
> 
>> On Feb 1, 2018, at 5:55 AM, R. Victor Klassen  
>> wrote:
>> 
>> Broke in pango - errors below:
>> 
>> [Is there a file or other accessible reference that I can look into to 
>> get some idea of what fraction of the way through I am?]
>> 
>> 
>> *** Configuring pango *** [17/65]
>> autoreconf -fi
>> acinclude.m4:68: warning: the serial number must appear before any macro 
>> definition
>> libtoolize: putting auxiliary files in '.'.
>> libtoolize: copying file './ltmain.sh'
>> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
>> libtoolize: and rerunning libtoolize and aclocal.
>> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>> acinclude.m4:68: warning: the serial number must appear before any macro 
>> definition
>> configure.ac:115: installing './compile'
>> configure.ac:52: installing './missing'
>> gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in 
>> AM_CONDITIONAL
>> docs/Makefile.am:101:   'gtk-doc.make' included from here

Re: Building unstable on Mac

[John Ralls]

Please remember to copy the list on all replies.

Well, if it was installed then why isn't libsoup finding it?

Regards,
John Ralls

> On Feb 1, 2018, at 2:50 PM, R. Victor Klassen  wrote:
> 
> … or what happened that it wasn’t found?
> 
> I scrolled back (actually used find) and it was checked out, configured, 
> built and installed.  These appeared successful.
> 
> That was two packages before libsoup.
> 
>> 
>> glib-networking is in the list of modules that should be built. What 
>> happened that it wasn't?
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> 
>>> On Feb 1, 2018, at 2:02 PM, R. Victor Klassen  wrote:
>>> 
>>> At some point I got the “refusing to switch to a dirty tree” error.  I 
>>> followed the instructions at 
>>> https://lists.gnucash.org/pipermail/gnucash-devel/2015-March/038616.html
>>> 
>>> [git reset --hard HEAD]
>>> 
>>> Hope that’s OK.
>>> 
>>> Next thing I remember is Boost.   That was almost impossible to check out.  
>>> For whatever reason, it would abort somewhere between 2% and 92% of the way 
>>> through the download.   Then finally it worked.
>>> 
>>> I followed the instructions on getting Boost to compile; at the instruction:
>>> 
>>> for i in `ls $PREFIX/lib/libboost*`; do install_name_tool -id $i $i; done 
>>> 
>>> I encountered a long series of errors of the form:
>>> 
>>> error: 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>>>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_atomic.a is 
>>> not a Mach-O file
>>> error: 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>>>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_chrono.a is 
>>> not a Mach-O file
>>> error: 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>>>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_container.a is 
>>> not a Mach-O file
>>> error: 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>>>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_coroutine.a is 
>>> not a Mach-O file
>>> 
>>> I continued, but I do wonder whether that was OK.
>>> 
>>> It did crash on the second ‘2’, as predicted, so I ran 
>>> 
>>> jhbuild build --start-at=googletest
>>> 
>>> Which picked up from there.  This failed in configure:
>>> 
>>> checking for glib-networking (glib TLS implementation)... no
>>> configure: error: libsoup requires glib-networking for TLS support.
>>> 
>>> If you are building a package, you can pass --disable-tls-check to
>>> allow building libsoup anyway (since glib-networking is not actually
>>> required at compile time), but you should be sure to add a runtime
>>> dependency on it.
>>> *** Error during phase configure of libsoup: ## Error running 
>>> ./configure --prefix /Users/gnucashdev/gnucash-unstable 
>>> set_more_warnings=no   *** [6/8]
>>> 
>>> I think it’s getting close...
>>> 
 On Feb 1, 2018, at 10:12 AM, John Ralls  wrote:
 
 You didn’t build gtk-doc and Pango requires at least the macros for it.
 
 As to your question, it depends. It’s telling you on the line just below 
 your question that pango is the seventeenth out of sixty-five packages, 
 but it doesn’t know that some of them build in a couple of seconds and 
 others (webkit and guile in particular) take hours.
 
 Regards,
 John Ralls
 
> On Feb 1, 2018, at 5:55 AM, R. Victor Klassen  wrote:
> 
> Broke in pango - errors below:
> 
> [Is there a file or other accessible reference that I can look into to 
> get some idea of what fraction of the way through I am?]
> 
> 
> *** Configuring pango *** [17/65]
> autoreconf -fi
> acinclude.m4:68: warning: the serial number must appear before any macro 
> definition
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> acinclude.m4:68: warning: the serial number must appear before any macro 
> definition
> configure.ac:115: installing './compile'
> configure.ac:52: installing './missing'
> gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in 
> AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> gtk-doc.make:60: error: GTK_DOC_BUILD_HTML does not appear in 
> AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> gtk-doc.make:65: error: GTK_DOC_BUILD_PDF does not appear in 
> AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> 

Re: Building unstable on Mac

[John Ralls]

Yes, "refusing to switch a dirty tree" comes from xmlsec because it has 
configuration products committed into its repo. You can actually just 2 -- 
ignore and continue to configure.

The boost line should be "for i in `ls $PREFIX\lib\libboost*.dylib`..." just 
like the one underneath it. I changed that in git 2 months ago but forgot to 
change the wiki page. Fixed now.

glib-networking is in the list of modules that should be built. What happened 
that it wasn't?

Regards,
John Ralls



> On Feb 1, 2018, at 2:02 PM, R. Victor Klassen  wrote:
> 
> At some point I got the “refusing to switch to a dirty tree” error.  I 
> followed the instructions at 
> https://lists.gnucash.org/pipermail/gnucash-devel/2015-March/038616.html
> 
> [git reset --hard HEAD]
> 
> Hope that’s OK.
> 
> Next thing I remember is Boost.   That was almost impossible to check out.  
> For whatever reason, it would abort somewhere between 2% and 92% of the way 
> through the download.   Then finally it worked.
> 
> I followed the instructions on getting Boost to compile; at the instruction:
> 
> for i in `ls $PREFIX/lib/libboost*`; do install_name_tool -id $i $i; done 
> 
> I encountered a long series of errors of the form:
> 
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_atomic.a is not 
> a Mach-O file
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_chrono.a is not 
> a Mach-O file
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_container.a is 
> not a Mach-O file
> error: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>  input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_coroutine.a is 
> not a Mach-O file
> 
> I continued, but I do wonder whether that was OK.
> 
> It did crash on the second ‘2’, as predicted, so I ran 
> 
> jhbuild build --start-at=googletest
> 
> Which picked up from there.  This failed in configure:
> 
> checking for glib-networking (glib TLS implementation)... no
> configure: error: libsoup requires glib-networking for TLS support.
> 
> If you are building a package, you can pass --disable-tls-check to
> allow building libsoup anyway (since glib-networking is not actually
> required at compile time), but you should be sure to add a runtime
> dependency on it.
> *** Error during phase configure of libsoup: ## Error running 
> ./configure --prefix /Users/gnucashdev/gnucash-unstable set_more_warnings=no  
>  *** [6/8]
> 
> I think it’s getting close...
> 
>> On Feb 1, 2018, at 10:12 AM, John Ralls  wrote:
>> 
>> You didn’t build gtk-doc and Pango requires at least the macros for it.
>> 
>> As to your question, it depends. It’s telling you on the line just below 
>> your question that pango is the seventeenth out of sixty-five packages, but 
>> it doesn’t know that some of them build in a couple of seconds and others 
>> (webkit and guile in particular) take hours.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Feb 1, 2018, at 5:55 AM, R. Victor Klassen  wrote:
>>> 
>>> Broke in pango - errors below:
>>> 
>>> [Is there a file or other accessible reference that I can look into to get 
>>> some idea of what fraction of the way through I am?]
>>> 
>>> 
>>> *** Configuring pango *** [17/65]
>>> autoreconf -fi
>>> acinclude.m4:68: warning: the serial number must appear before any macro 
>>> definition
>>> libtoolize: putting auxiliary files in '.'.
>>> libtoolize: copying file './ltmain.sh'
>>> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
>>> libtoolize: and rerunning libtoolize and aclocal.
>>> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>>> acinclude.m4:68: warning: the serial number must appear before any macro 
>>> definition
>>> configure.ac:115: installing './compile'
>>> configure.ac:52: installing './missing'
>>> gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
>>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>>> gtk-doc.make:60: error: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
>>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>>> gtk-doc.make:65: error: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
>>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>>> gtk-doc.make:74: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
>>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>>> gtk-doc.make:280: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL
>>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>>> docs/Makefile.am:142: error: 

Re: Building unstable on Mac

[R. Victor Klassen]

At some point I got the “refusing to switch to a dirty tree” error.  I followed 
the instructions at 
https://lists.gnucash.org/pipermail/gnucash-devel/2015-March/038616.html 


[git reset --hard HEAD]

Hope that’s OK.

Next thing I remember is Boost.   That was almost impossible to check out.  For 
whatever reason, it would abort somewhere between 2% and 92% of the way through 
the download.   Then finally it worked.

I followed the instructions on getting Boost to compile; at the instruction:

for i in `ls $PREFIX/lib/libboost*`; do install_name_tool -id $i $i; done 

I encountered a long series of errors of the form:

error: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
 input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_atomic.a is not a 
Mach-O file
error: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
 input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_chrono.a is not a 
Mach-O file
error: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
 input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_container.a is not 
a Mach-O file
error: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
 input file: /Users/gnucashdev/gnucash-unstable/lib/libboost_coroutine.a is not 
a Mach-O file

I continued, but I do wonder whether that was OK.

It did crash on the second ‘2’, as predicted, so I ran 

jhbuild build --start-at=googletest

Which picked up from there.  This failed in configure:

checking for glib-networking (glib TLS implementation)... no
configure: error: libsoup requires glib-networking for TLS support.

If you are building a package, you can pass --disable-tls-check to
allow building libsoup anyway (since glib-networking is not actually
required at compile time), but you should be sure to add a runtime
dependency on it.
*** Error during phase configure of libsoup: ## Error running 
./configure --prefix /Users/gnucashdev/gnucash-unstable set_more_warnings=no   
*** [6/8]

I think it’s getting close...

> On Feb 1, 2018, at 10:12 AM, John Ralls  wrote:
> 
> You didn’t build gtk-doc and Pango requires at least the macros for it.
> 
> As to your question, it depends. It’s telling you on the line just below your 
> question that pango is the seventeenth out of sixty-five packages, but it 
> doesn’t know that some of them build in a couple of seconds and others 
> (webkit and guile in particular) take hours.
> 
> Regards,
> John Ralls
> 
>> On Feb 1, 2018, at 5:55 AM, R. Victor Klassen > > wrote:
>> 
>> Broke in pango - errors below:
>> 
>> [Is there a file or other accessible reference that I can look into to get 
>> some idea of what fraction of the way through I am?]
>> 
>> 
>> *** Configuring pango *** [17/65]
>> autoreconf -fi
>> acinclude.m4:68: warning: the serial number must appear before any macro 
>> definition
>> libtoolize: putting auxiliary files in '.'.
>> libtoolize: copying file './ltmain.sh'
>> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
>> libtoolize: and rerunning libtoolize and aclocal.
>> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>> acinclude.m4:68: warning: the serial number must appear before any macro 
>> definition
>> configure.ac:115: installing './compile'
>> configure.ac:52: installing './missing'
>> gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>> gtk-doc.make:60: error: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>> gtk-doc.make:65: error: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>> gtk-doc.make:74: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>> gtk-doc.make:280: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL
>> docs/Makefile.am:101:   'gtk-doc.make' included from here
>> docs/Makefile.am:142: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
>> docs/Makefile.am:54: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
>> (or '*_CPPFLAGS')
>> examples/Makefile.am:6: warning: 'INCLUDES' is the old name for 
>> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
>> examples/Makefile.am: installing './depcomp'
>> pango-view/Makefile.am:30: warning: 'INCLUDES' is the old name for 
>> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
>> pango/Makefile.am:16: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
>> (or '*_CPPFLAGS')
>> pango/mini-fribidi/Makefile.am:3: warning: 'INCLUDES' is the old name for 
>> 'AM_CPPFLAGS' (or '*_CPPFLAGS')

Re: Building unstable on Mac

[John Ralls]

You didn’t build gtk-doc and Pango requires at least the macros for it.

As to your question, it depends. It’s telling you on the line just below your 
question that pango is the seventeenth out of sixty-five packages, but it 
doesn’t know that some of them build in a couple of seconds and others (webkit 
and guile in particular) take hours.

Regards,
John Ralls

> On Feb 1, 2018, at 5:55 AM, R. Victor Klassen  wrote:
> 
> Broke in pango - errors below:
> 
> [Is there a file or other accessible reference that I can look into to get 
> some idea of what fraction of the way through I am?]
> 
> 
> *** Configuring pango *** [17/65]
> autoreconf -fi
> acinclude.m4:68: warning: the serial number must appear before any macro 
> definition
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> acinclude.m4:68: warning: the serial number must appear before any macro 
> definition
> configure.ac:115: installing './compile'
> configure.ac:52: installing './missing'
> gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> gtk-doc.make:60: error: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> gtk-doc.make:65: error: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> gtk-doc.make:74: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> gtk-doc.make:280: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL
> docs/Makefile.am:101:   'gtk-doc.make' included from here
> docs/Makefile.am:142: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
> docs/Makefile.am:54: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
> (or '*_CPPFLAGS')
> examples/Makefile.am:6: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
> (or '*_CPPFLAGS')
> examples/Makefile.am: installing './depcomp'
> pango-view/Makefile.am:30: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> pango/Makefile.am:16: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
> (or '*_CPPFLAGS')
> pango/mini-fribidi/Makefile.am:3: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> tools/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
> (or '*_CPPFLAGS')
> win32/Makefile-newvs.am:23: warning: MSVC_TOOLSET was already defined in 
> condition TRUE, which includes condition MSVC_NO_TOOLSET_SET ...
> win32/vs15/Makefile.am:30:   'win32/Makefile-newvs.am' included from here
> win32/vs15/Makefile.am:28: ... 'MSVC_TOOLSET' previously defined here
> autoreconf: automake failed with exit status: 1
> *** Error during phase configure of pango: ## Error running 
> autoreconf -fi *** [17/65]
> 
>   [1] Rerun phase configure
>   [2] Ignore error and continue to build
>   [3] Give up on module
>   [4] Start shell
>   [5] Reload configuration
>   [6] Go to phase "wipe directory and start over"
>   [7] Go to phase "clean"
>   [8] Go to phase "distclean"
> choice: 
> 
> 
>> On Jan 29, 2018, at 11:02 PM, John Ralls > > wrote:
>> 
>> To build unstable:
>> 
>> 1. Retrieve the latest .jhbuildrc-custom from the gnucash-on-osx repository.
>> 2. Edit ~/.jhbuildrc-custom to comment out the gnucash-stable prefix and 
>> modules and to uncomment the gnucash-unstable ones.
>> 3. Run jhbuild bootstrap
>> 4. Run jhbuild build
>> 
>> If you want a git checkout, uncomment the gnucash-git module instead of the 
>> gnucash-unstable module. That will build ‘master’, though be sure to look at 
>> https://github.com/jralls/gnucash-on-osx/blob/master/modulesets/gnucash.modules
>>  
>> 
>>  and note the instructions for boost; jhbuild doesn’t know how to build 
>> that. After running `jhbuild build` you can
>> 
>> 1. cd ~/gtk/source/gnucash-git
>> 2. git clean -fdx
>> 2. git checkout -b unstable -t origin/unstable
>> 3. jhbuild shell
>> 4. cd $PREFIX/..
>> 5. mkdir build/gnucash-git && cd build/gnucash-git
>> 6. cmake -DCMAKE_INSTALL_PREFIX=$PREFIX 
>> -DGTEST_ROOT=$JHBUILD_SOURCE/googletest/googletest 
>> -DGMOCK_ROOT=$JHBUILD_SOURCE/googletest/googlemock 
>> $JHBUILD_SOURCE/gnucash-git
>> 7. make && make install
>> 
>> To run tests, run 
>>   make check
>> 
>> Regards,
>> John Ralls
>> 
>>> On Jan 29, 2018, at 3:33 PM, R. Victor Klassen >> > wrote:
>>> 
>>> So, the wiki is less than clear on how to do this.
>>> 
>>> First I tried going through the instructions under Building for Development 
>>> beginning with

Re: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Feb 1, 2018, at 8:22 AM, Christopher Lam  wrote:
> 
> Hi Adrien,
> 
> From reviewing the code, I still believe the (b)udget transactions system 
> works better. The current code calculates all Reconciled/Cleared/Unreconciled 
> balances on the fly, and it'll be pretty easy to add one for Budget balances. 
> If I'm right, a book with large number of transactions over years will 
> require perhaps 20 (b)udget transactions per year, which will hardly be 
> straining the datafile or the code.
> 
> It is also compatible with the suggestion for "manually triggered SX" or 
> "transaction templates”.

That enhancement was only for an actual transaction that moves money from a 
parent to sub-accounts. I didn’t intend that as a separate layer ‘virtual’ 
transaction. But yes, I see it could work for both.

> 
> The only feature that the envelope system doesn't support is an 'expiry date' 
> for the budget -- some people may prefer monthly/quarterly/annual budgets, 
> and so far I can't think how this would work. The register would really just 
> need color coding to identify 'balance too close to budget' situations.

My understanding is that the envelopes don’t expire, it’s a retained ‘savings’ 
so I get they don’t have a date. That doesn’t preclude budgeting by period 
though. Say you set a spending budget of $100/$300/$1200 for dining out 
(monthly, quarterly, yearly) then you use that as your envelope goal. As you 
allocate, you can see if you have hit your goal. (if so, the allocation stops) 
If you end up spending under budget, that money remains allocated. (unless you 
flow it somewhere else) You’ll just have a head start in your savings plan when 
the next period cycles around. An additional calculation would be needed here. 
At any point in time, you’d need to see the remaining goal to be saved for. 

There should also be a mechanism for letting the user decide how to control the 
allocation or flow of money to the envelopes. This could be a ‘stop’ situation 
based on if either the monthly, quarterly, or yearly goals are reached. Someone 
might want to set a high % to be allocated until perhaps one or two quarters 
are saved up, then back off a bit. Or they might want to leave it high until 
the goal is reached, but keep saving at a lower level. (that part is good for 
emergency funds or debt retirement) Or they might want to only allocate each 
month until the goal is reached (which might be the first pay check) and then 
stop until the month rolls over.

I know this is sounding more complicated, but if the user can’t control their 
savings rate and plan, they probably aren’t going to use the feature much.

By the way, I do like the idea of some sort of color warning with respect to 
hitting budget limits.
> 
> Try opening a register and see View > Filter by... > Status you'll see all 5 
> statuses are ticked. If by default the suggested "b" transactions are 
> disabled then the average user will never see them.

That changes things entirely. I see no UX issues then.
> 
> My suggestion also obviates the need for the shadow accounts as your 
> recommendation.
> 
> IMHO Using a separate kvp system will lead to performance issues similar to 
> current Budget on Windows.
I’ve heard there was some problems there but didn’t realize that was the cause. 
I wonder why that is. Since the user doesn’t have to be exposed to the budget 
transactions by default, I don’t see an issue changing to that method then. 
Whatever is most efficient.

On that note you might need two status levels. A ‘b’ for ‘budget’ to handle the 
current functionality and an ‘e/s’ for ‘envelopes/savings’ to handle savings 
toward those budget goals.
> 
> I'm rather tempted to hack the code to calculate the budgeted amounts by 
> abusing the current (v)oid transactions UI, and it seems very doable :-o

Let me know when you do. I’d be interested in seeing the work and in testing. 
And I’ll be happy to help where I can.

Regards,
Adrien


> 
> Chris
> 
> 
> On 01/02/18 22:05, Adrien Monteleone wrote:
>>> On Jan 31, 2018, at 2:48 PM, Phil Longstaff  
>>> wrote:
>>> 
>>> 
>>> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone 
>>> > wrote:
>>> 
>>> 
 On Jan 31, 2018, at 10:09 AM, Christopher Lam > wrote:
 
 Hi Matt- I thought this should move to the devel list, because of 
 technical details, and this discussion will be very speculative.
 
 I had a thought about how envelope budgeting could work: "divide your 
 paycheck into separate envelopes for different purposes".
 
 A solution: *Create another type of transaction.*
 
 There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
 transactions. And (f)rozen I believe is unused. Let's create a new type - 
 (b)udget. But the balances are handled 

Re: Future allocated money, aka Envelope Budgeting

[Christopher Lam]

Hi Adrien,

From reviewing the code, I still believe the (b)udget transactions 
system works better. The current code calculates all 
Reconciled/Cleared/Unreconciled balances on the fly, and it'll be pretty 
easy to add one for Budget balances. If I'm right, a book with large 
number of transactions over years will require perhaps 20 (b)udget 
transactions per year, which will hardly be straining the datafile or 
the code.


It is also compatible with the suggestion for "manually triggered SX" or 
"transaction templates".


The only feature that the envelope system doesn't support is an 'expiry 
date' for the budget -- some people may prefer monthly/quarterly/annual 
budgets, and so far I can't think how this would work. The register 
would really just need color coding to identify 'balance too close to 
budget' situations.


Try opening a register and see View > Filter by... > Status you'll see 
all 5 statuses are ticked. If by default the suggested "b" transactions 
are disabled then the average user will never see them.


My suggestion also obviates the need for the shadow accounts as your 
recommendation.


IMHO Using a separate kvp system will lead to performance issues similar 
to current Budget on Windows.


I'm rather tempted to hack the code to calculate the budgeted amounts by 
abusing the current (v)oid transactions UI, and it seems very doable :-o


Chris


On 01/02/18 22:05, Adrien Monteleone wrote:

On Jan 31, 2018, at 2:48 PM, Phil Longstaff  wrote:


On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone > wrote:



On Jan 31, 2018, at 10:09 AM, Christopher Lam > wrote:

Hi Matt- I thought this should move to the devel list, because of technical 
details, and this discussion will be very speculative.

I had a thought about how envelope budgeting could work: "divide your paycheck into 
separate envelopes for different purposes".

A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid transactions. 
And (f)rozen I believe is unused. Let's create a new type - (b)udget. But the 
balances are handled differently.

It would require some UI and calculations changes --

1. The account budget balance is always maintained similarly to 
Running/Reconciled/Cleared Balances. But it would count all previous 
split-values *and* the (b)udget split amounts. However the budget running 
balance is not shown in the default register. This means, existing 
balances/register are unchanged.

Having transactions in an account register that don’t affect the balance is 
going to be very problematic. I think this would really confuse users.

I would think budget levels for each expense account could be exposed in the 
properties/preferences for each one.

That's basically how it's done now. It uses the kvp (key-value pair) mechanism 
and each account has a kvp per budget per period with the budget amount.

But I see they aren’t exposed in the Account Edit window. The only way to see 
what was budgeted is to open the budget module, or to see what’s left is to run 
a budget report. And even that part is limited as it’s only a all-or-nothing 
figure for the year, not year-to-date.

Regards,
Adrien
  


The allocation of budget money would have to be handled with a special dialog 
on demand, or as part of an income/asset account preferences with 
percentages/formulas. (essentially a template transaction that fires when 
entries are made in that account)

We already have a budgeting mechanism to set how much we *want* to spend on a 
particular expense.

What we’re discussing here is a way to ‘save up’ funds received for each of 
those expenses.

If I understand correctly, the budget module uses hidden accounts to keep track 
of everything. I would think these same accounts, or other hidden accounts 
paired with them, could do the job.

This is incorrect. It uses kvp (key-value pair) structures attached to each 
account.
  
Phil

Thanks for clearing that up. Certainly, that seems the more sane route. I would 
think another set of kvp could be implemented to handle the envelope system 
then. One set to hold the amount already allocated and another to hold the 
allocation formula. The original budget pair could be used as the goal.

___
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: Future allocated money, aka Envelope Budgeting

[Adrien Monteleone]

> On Jan 31, 2018, at 2:48 PM, Phil Longstaff  wrote:
> 
> 
> On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone 
> > wrote:
> 
> 
> > On Jan 31, 2018, at 10:09 AM, Christopher Lam  > > wrote:
> >
> > Hi Matt- I thought this should move to the devel list, because of technical 
> > details, and this discussion will be very speculative.
> >
> > I had a thought about how envelope budgeting could work: "divide your 
> > paycheck into separate envelopes for different purposes".
> >
> > A solution: *Create another type of transaction.*
> >
> > There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
> > transactions. And (f)rozen I believe is unused. Let's create a new type - 
> > (b)udget. But the balances are handled differently.
> >
> > It would require some UI and calculations changes --
> >
> > 1. The account budget balance is always maintained similarly to 
> > Running/Reconciled/Cleared Balances. But it would count all previous 
> > split-values *and* the (b)udget split amounts. However the budget running 
> > balance is not shown in the default register. This means, existing 
> > balances/register are unchanged.
> 
> Having transactions in an account register that don’t affect the balance is 
> going to be very problematic. I think this would really confuse users.
> 
> I would think budget levels for each expense account could be exposed in the 
> properties/preferences for each one.
> 
> That's basically how it's done now. It uses the kvp (key-value pair) 
> mechanism and each account has a kvp per budget per period with the budget 
> amount.

But I see they aren’t exposed in the Account Edit window. The only way to see 
what was budgeted is to open the budget module, or to see what’s left is to run 
a budget report. And even that part is limited as it’s only a all-or-nothing 
figure for the year, not year-to-date.

Regards,
Adrien
>  
> 
> The allocation of budget money would have to be handled with a special dialog 
> on demand, or as part of an income/asset account preferences with 
> percentages/formulas. (essentially a template transaction that fires when 
> entries are made in that account)
> 
> We already have a budgeting mechanism to set how much we *want* to spend on a 
> particular expense.
> 
> What we’re discussing here is a way to ‘save up’ funds received for each of 
> those expenses.
> 
> If I understand correctly, the budget module uses hidden accounts to keep 
> track of everything. I would think these same accounts, or other hidden 
> accounts paired with them, could do the job.
> 
> This is incorrect. It uses kvp (key-value pair) structures attached to each 
> account.
>  
> Phil

Thanks for clearing that up. Certainly, that seems the more sane route. I would 
think another set of kvp could be implemented to handle the envelope system 
then. One set to hold the amount already allocated and another to hold the 
allocation formula. The original budget pair could be used as the goal.

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

Re: Building unstable on Mac

[R. Victor Klassen]

Broke in pango - errors below:

[Is there a file or other accessible reference that I can look into to get some 
idea of what fraction of the way through I am?]


*** Configuring pango *** [17/65]
autoreconf -fi
acinclude.m4:68: warning: the serial number must appear before any macro 
definition
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
acinclude.m4:68: warning: the serial number must appear before any macro 
definition
configure.ac:115: installing './compile'
configure.ac:52: installing './missing'
gtk-doc.make:7: error: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
docs/Makefile.am:101:   'gtk-doc.make' included from here
gtk-doc.make:60: error: GTK_DOC_BUILD_HTML does not appear in AM_CONDITIONAL
docs/Makefile.am:101:   'gtk-doc.make' included from here
gtk-doc.make:65: error: GTK_DOC_BUILD_PDF does not appear in AM_CONDITIONAL
docs/Makefile.am:101:   'gtk-doc.make' included from here
gtk-doc.make:74: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
docs/Makefile.am:101:   'gtk-doc.make' included from here
gtk-doc.make:280: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL
docs/Makefile.am:101:   'gtk-doc.make' included from here
docs/Makefile.am:142: error: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
docs/Makefile.am:54: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or 
'*_CPPFLAGS')
examples/Makefile.am:6: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
(or '*_CPPFLAGS')
examples/Makefile.am: installing './depcomp'
pango-view/Makefile.am:30: warning: 'INCLUDES' is the old name for 
'AM_CPPFLAGS' (or '*_CPPFLAGS')
pango/Makefile.am:16: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or 
'*_CPPFLAGS')
pango/mini-fribidi/Makefile.am:3: warning: 'INCLUDES' is the old name for 
'AM_CPPFLAGS' (or '*_CPPFLAGS')
tools/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or 
'*_CPPFLAGS')
win32/Makefile-newvs.am:23: warning: MSVC_TOOLSET was already defined in 
condition TRUE, which includes condition MSVC_NO_TOOLSET_SET ...
win32/vs15/Makefile.am:30:   'win32/Makefile-newvs.am' included from here
win32/vs15/Makefile.am:28: ... 'MSVC_TOOLSET' previously defined here
autoreconf: automake failed with exit status: 1
*** Error during phase configure of pango: ## Error running autoreconf 
-fi *** [17/65]

  [1] Rerun phase configure
  [2] Ignore error and continue to build
  [3] Give up on module
  [4] Start shell
  [5] Reload configuration
  [6] Go to phase "wipe directory and start over"
  [7] Go to phase "clean"
  [8] Go to phase "distclean"
choice: 


> On Jan 29, 2018, at 11:02 PM, John Ralls  wrote:
> 
> To build unstable:
> 
> 1. Retrieve the latest .jhbuildrc-custom from the gnucash-on-osx repository.
> 2. Edit ~/.jhbuildrc-custom to comment out the gnucash-stable prefix and 
> modules and to uncomment the gnucash-unstable ones.
> 3. Run jhbuild bootstrap
> 4. Run jhbuild build
> 
> If you want a git checkout, uncomment the gnucash-git module instead of the 
> gnucash-unstable module. That will build ‘master’, though be sure to look at 
> https://github.com/jralls/gnucash-on-osx/blob/master/modulesets/gnucash.modules
>  
> 
>  and note the instructions for boost; jhbuild doesn’t know how to build that. 
> After running `jhbuild build` you can
> 
> 1. cd ~/gtk/source/gnucash-git
> 2. git clean -fdx
> 2. git checkout -b unstable -t origin/unstable
> 3. jhbuild shell
> 4. cd $PREFIX/..
> 5. mkdir build/gnucash-git && cd build/gnucash-git
> 6. cmake -DCMAKE_INSTALL_PREFIX=$PREFIX 
> -DGTEST_ROOT=$JHBUILD_SOURCE/googletest/googletest 
> -DGMOCK_ROOT=$JHBUILD_SOURCE/googletest/googlemock $JHBUILD_SOURCE/gnucash-git
> 7. make && make install
> 
> To run tests, run 
>   make check
> 
> Regards,
> John Ralls
> 
>> On Jan 29, 2018, at 3:33 PM, R. Victor Klassen > > wrote:
>> 
>> So, the wiki is less than clear on how to do this.
>> 
>> First I tried going through the instructions under Building for Development 
>> beginning with
>> 
>> jhbuild shell
>> cd $PREFIX/../src/gnucash-2.6.17
>> But it turned out that there was no path with the prefix $PREFIX/../src
>> 
>> No src directory had yet been created under $PREFIX - this is a clean user 
>> account, with most of an attempt at building stable as the only thing in it.
>> 
>> So I skipped the uninstall, and made a guess as to where I was supposed to 
>> go with the cd ..
>> 
>> Then I ran
>> 
>> git clone -b maint https://github.com/Gnucash/gnucash.git 
>> 
>> Nearly giving up after a dozen or so failures to get the whole thing in one 
>> gulp.  Early morning seems best.
>> 

Re: Which doc directory

[Geert Janssens]

Op dinsdag 30 januari 2018 17:33:12 CET schreef Robert Fewell:
> Hi,
> 
> I have two usr/share/doc directories related to Gnucash, they are...
> 
> /usr/share/doc/Gnucash with Changelogs... and HACKING,NEWS etc...
> /use/share/doc/gnucash with abc.qif, web.qif etc...
> 
> I am not sure which is correct but the doc\CMakeLists,txt is pointing to
> 'doc/gnucash' while the main CMakeLists.txt is using CMAKE_INSTALL_DOCDIR.
> 

Good catch.

I think we should stick with all lowercase because that's what is used 
everywhere else when the gnucash name is used in file paths.

I need to fix this for the gnc_userdata_dir as well.

Geert


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