> For anyone with the same troubles, here's what I did: > 1) configure failed to detect my xsltproc binary, so I had to change > "XSLTPROC='no'" to "XSLTPROC=/usr/bin/xsltproc", otherwise, build.sh > fails because it doesn't know how to execute "no"
maybe you don't have /usr/bin in the PATH :) the configure script does a AC_PATH_PROG to check automatically for the xsltproc path. > 2) when running build.sh, it bailed out complaining that the sqlite > database was full (in mkindex.php). This happened during VACUUM, which, > while beneficial, is not necessary, so comment out the line > "sqlite_query($idx, 'VACUUM full_search');" in mkindex.php This work perfectly on my two pcs. VACUUM is just a performance hack for SQLite. You need sqlite >= 2.8.1. > 3) when using any of the themes, I had to link /path/to/livedocs/themes > to /path/to/webroot/themes I never had problems with this... neither on windows or linux! > Other caveats: > - when giving configure a --with-build-log, build.sh is annoyingly > silent. It's much more convenient for me to ./build.sh | tee > my_own_build.log, and exclude that configure option. Livedocs build process is aimed to be run by cron... Just type the build command and relax :) Livedocs works! > - ignore the MANY lines that start with "BAD ID", when running build.sh, > I guess they don't matter. They exist, so they matter :) As livedocs is still in an earlier stage you will find many usefull debug info (some hidden in HTML comments). If you trace some problem, you can send me the info and I'll try to solve the problem. My programming skills aren't very good, but I'll try ;) About my patches: I've posted that patches in my website just to don't lost them. Some are tested and can be commited, but some are just proof-of-concept. They can be used later by Ilia, Wez or Derick to fix the problems that I've found (and they may be aware of, but hadn't time to fix yet). The patches have a simple explanation of the problem and of my fix. Creating branches or even other module for livedocs isn't a solution IMHO. The best option is to have an oficial livedocs patch queue (this was proposed by the docs.php.net project), so that they can be reviewed, improved and commited/deleted. Nuno
