Path problem in staged build (choosing between staged build or normal - but not both)?

[Johan Persson]

In my project I use Docbook t(with XSL stylesheets) o generate a user
manual which works fine. However I found myself in a conundrum when it
comes to handling all the paths so that the build works both when
building in the source tree and using a staged build (needed to have a
clean distcheck) 

I think I fully understands the issue but have not come up with a clean
way to handle it with autoconf/automake. Let me see if I can explain
this in a clear way 

1. Different Linux distributions store the Docbook XSL (needed to
translate the source XML files) in different places. 

2. I use customized XSL sheets which needs to include the absolute paths
to the distributions Docbook original XSL file. 

3. To cope with this the config process figures out the absolute paths
to the Docbook XSL and generates the correct customized "*xsl" files
from a set of "*.xsl.in" (normal config file handling). 

So far so good, and this works perfect when building the in the original
source tree. The problem now comes when doing a staged build. 

In addition to these XSL files the manual also uses a number of
additional resources (for example images) which are in the source tree.
Since they are not generated in the config process they remain in the
original source tree (and not in the staged path). 

Since the customized files are generated in the staged path the XSL
processing will assume that all resource are relative to that (staged)
directory and this is the problem! Most resources are NOT in the staged
path but in the original source tree. 

Hence a staged build will fail since the xsl process fails to find a
number of resources since they remain in the original (read-only) source
tree. 

The (non) solutions I have thought of (and rejected) are: 

1. Copy the resources into the staging path (with an extra recipe in the
makefile).
Not a good idea since this gets complicated since the movement should
not be made when doing a build in the original tree but only for a
staged build. Furthermore, "distclean" will give an error if these files
are not manually removed again with another recipe and only when doing a
staged build 

2. Configure the source XML file to adjust the paths. Not a good idea
since this makes it impossible to see the real image files when editing
the source XML since the path will have an unresolved shell variable at
the time of writing 

3. Just supporting one specific distribution which avoids generating XSL
files in the staging are and keep the entire build process in the
original source tree. This works fine for both in-tree and out-tree
builds (using the vpath) 

4. A variant of (3) is to have multiple set of the XSL files with a set
for each distribution and choose he appropriate one in the makefile with
the help of config variables. Again, this avoids the core problem of
having XSL resources in different paths.This adds to the maintenance
burden 

5. Asking the user to adjust his Docbook paths to suit the one the build
assumed. Bad for so many reasons 

Solution (4) is probably something I can live with since in practice
there is only really 2-3 different places for the Docbook installation. 

However, none of these seem very clean to me and I can't keep wondering
if I miss some automake trick (like the one for handling absolute paths
for daemons) 

Any thought?