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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
