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

[Neil Williams]

On Monday 09 January 2006 9:22 am, you wrote:
> That's right - my wording was inaccurate. It's not absolute in
> configure.in, but it's absolute in lib/libqof/backend/file/Makefile
> where other similar paths there usually still include the ${prefix}
> variable.

That's because the value is a defined macro - it needs to be expanded fully.

This expansion fully takes into account the prefix specified. It is also part 
of the AC_OUTPUT - fully expanded.

n.b. This discussion is all about *packaging*, not the code itself.

> 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. The backend must know where to find the 
XML schema. QOF_XML_DIR needs to be an absolute path - but it's a path that 
is ALWAYS created entirely from the switches given to ./configure so that 
each distribution can put the schema in whatever places are preferred.

This isn't a path to a library that make can link against the built sources, 
this is a path to runtime files that can be installed anywhere on the system. 
Make does not need to know where these files are located, it is sufficient 
that the packaging scripts can locate the files and incorporate them into the 
binary package. These are not user files (so ~ isn't used), these are system 
- package - files and it is up to the PACKAGER to decide and handle the 
location of the files. This entire process is open to the packager to 
configure - nothing is assumed in advance except appending xml/qsf/ to 
whatever the *packager* specified.

The code is fine, it works on all other platforms and it works within a 
opt-style-install - all that is needed is for the package maintainer to 
adjust the packaging scripts to put the schema in the location specified by 
the packager's own instructions to ./configure. There is no need for make 
distcheck or other package building code to actually read the schema OR to 
put the schema in a place that is accessible to the package code within the 
packaging process - these are runtime only files. All that is required is 
that the schema are packaged, that the location of the schema is built into 
the binary package and that this path is fully expanded and configured to 
match whatever was specified to ./configure. Everyone can put the schema 
wherever they want, all that is required is that they actually put the files 
where they said they would be put! You can't blame the code if the packager 
puts the files in one directory but specifies another to the code!

This is why DESTDIR is the solution - it is merely a case of matching the make 
install location to that specified to ./configure on those platforms that do 
not do this automatically. Debian does, Fedora and OSX needed a minor tweak.

BTW. Gentoo should, IMHO, be using external QOF anyway.

> The whole point of the Makefile.am rules to create the bla.h files from
> the bla.h.in files (the rules with the comment "we borrowed convention
> from guile...") was to enable the latter one, because in the Makefile
> the ${datadir} will be evaluated to the current value of ${prefix} et
> al.,

No, that happens in configure.

> whereas in configure the variable ${prefix} is not yet set (which 
> is the "NONE" that you had to fix manually).

No. The NONE is a figment of OSX. ${prefix} is set by the switch given 
to ./configure.

> > Your original premise in inaccurate - the problem does not exist as
> > portrayed. If this was a bug report, I'd tag it "won't fix" and close it.
>
> This statement is missing a little bit of diplomacy... The original
> problem does exist as portrayed

But the premise of the problem is still inaccurate.

> or otherwise I wouldn't have reported 
> it. A proper solution needs to be discussed. DISTDIR may or may not be
> the proper solution, we'll see.

The proper solution is already in place. Remaining problems are solely the 
domain of the package maintainer(s). This is why I do the packaging myself 
for Debian and Fink and provide sample .spec files for Fedora RPM's - so that 
I know it works.

-- 

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/20060109/ba237629/attachment.bin