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

[Neil Williams]

On Tuesday 10 January 2006 1:06 pm, Christian Stimming wrote:
> 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.

Yes.

> 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.

Yes.

> 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.

If this is additional and keeps the other methods working, I'm more than happy 
to use it. I'll test with it - I suspect OSX is the one platform most likely 
to show any problems, it does do some very strange automake things.

> 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"

OK, I'll test with OSX and go from there.
(I really thought I'd tried this before going for the eval echo method, but 
I'll check it again.)

> 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.

Providing the same value is written into the C code as is used for the actual 
installation, yes. My way of ensuring this was to fully expand it.

> In gnucash's code, the variable QOF_XML_DIR is used in *one* single
> location, which is lib/libqof/backend/file/Makefile.am, 

Yes, although there is a secondary usage in configure.in AC_OUTPUT but that 
can be handled without altering the current discussions. (It's just part of 
the helpful configure completion message.)

> 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 .

Yes. 

>
> Have I missed a second usage of that variable? 

Not such that it would alter the current discussion. I sought to only generate 
this value once and use it from the header file for all later purposes.

> 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.

As long as OSX plays along, I'm happy.

> 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.

That is the method used in external QOF where backend/file/qsf-dir.h is 
created by AC_OUTPUT. GnuCash is written to only use Makefiles in that 
location. This value is then exported via the pkg-config routine.

> 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.

Let me test on OSX and I'll either let you know (if there are problems) or 
make the commit from this end.

As for the original problem, it sounds like using QOF as the (recommended) 
external dependency is a viable and beneficial solution.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060110/e37994c4/attachment.bin