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?
