libqof variables in configure.in (Fwd: gentoo ebuild)

[Christian Stimming]

Hi Neil,

to summarize the discussion so far:

1. The content of the QOF_XML_DIR variable needs to be defined as an 
absolute path when it is used in the C code for the current 
configuration of libqof, as otherwise the runtime would break (and 
unfortunately the build itself would not indicate an error). We both 
agree on this.

2. For packagers that use an intermediate sandbox for "make install" 
during packaging, "make DESTDIR=/my/sandbox install" is one possibility 
that is supported by the current usage of QOF_XML_DIR. We agree on this 
as well.

Now my proposal was as follows:

3. In *addition* to the "make DISTDIR..." solution I would like to 
enable Martin's/gentoo's original approach "make prefix=/my/sandbox 
install" as well. This would be an *additional* way for those 
sandbox-packaging, and that way is supported by automake in principle as 
well.

My proposed patch for configure.in IMHO would achieve #3 while keeping 
#1 working. At least that's what my local test confirms. Proposed patch:

 >         QOF_VERSION="internal"
 >         QOF_PREFIX="internal"
 > -       QOF_XML_DIR=`eval echo ${datadir}/xml/qsf`
 > +       QOF_XML_DIR="\${datadir}/xml/qsf"

and I explained:

>>Currently, on --prefix=/my/prefix, the Makefile will contain:
>>
>>QOF_XML_DIR=/my/prefix/share/xml/qsf
>>
>>With the proposed change, the Makefile will contain:
>>
>>QOF_XML_DIR=${datadir}/xml/qsf
> 
> Which will cause the backend to fail because it cannot find the schema - the C 
> code knows nothing of ${datadir} - that will be passed unchanged as a string. 
> The value of QOF_XML_DIR needs to be fully expanded so that it can be 
> incorporated into the built source. 

I agree on the latter part, "QOF_XML_DIR needs to be fully expanded", 
but I don't agree on the former. The point is that QOF_XML_DIR needs to 
be fully expanded *in the C code*, but not necessarily in the Makefile.

In gnucash's code, the variable QOF_XML_DIR is used in *one* single 
location, which is lib/libqof/backend/file/Makefile.am, where the 
evaluated value of this variable is used to insert the fully expanded 
path into the generated file lib/libqof/backend/file/qsf-dir.h, 
generated from qsf-dir.h.in .

Have I missed a second usage of that variable? Because if this is really 
the only use case, then on invoking the rule for qsf-dir.h, the value of 
QOF_XML_DIR will be assigned in the Makefile, and the part "${datadir}" 
of that assignment will be evaluated to the build-time value of 
${datadir}. The final value of QOF_XML_DIR that is used in the rule for 
qsf-dir.h will be precisely the desired absolute path without any 
undefined variables anymore.

Again, this effect is precisely the reason for adding manual rules for 
the foo.h.in -> foo.h substitutions. If this effect had not been needed, 
it would have been sufficient to list foo.h in the AC_CONFIG_FILES macro 
of configure.in and not list it again in any Makefile, which would save 
some typing. So since this rule achieves the effect it was designed for, 
we could as well make use of that desired effect.

That is why I propose to include the patch and enable the "make 
prefix=/my/sandbox install" possibility *in addition* to the already 
working methods.

Christian