> >> This causes problems with paths to input data files >> and forces each example to use complicated logic to calculate paths. > > True, particularly in Restrainer's case where you have paths embedded in your XML files - you can't use get_example_path() there. Can't you use relative paths there? eg the .xml file contains "./foo.dat" (or just "foo.dat") which should search for the data file relative to the input xml. Otherwise, either you can't relocate you setup or have to always run it from the same directory relative to the .xml file, both of which would be very annoying. Or perhaps I'm confused.

> >> Would it be a good idea to >> modify the build process to run examples from their respective >> directories? This way all examples can use the relative paths and if a >> user wishes to run an example, he/she can just cd to the example >> directory and run it directly from there. > > Yes, I agree - for running examples during the build, it should be straightforward enough to have the build system cd into build/doc/examples to run the example. That also ensures that any outputs generated by the example don't end up littering the source tree. The directory containing the examples isn't necessarily writable (say once they are installed), so we have to be careful about any files they write. I think it is reasonable to insist that the working directory is writeable to produce output, but we could also have the samples write to a tmp dir.

On Feb 10, 2010, at 11:43 AM, Ben Webb wrote:

> On 02/10/2010 11:33 AM, Daniel Russel wrote: >>> True, particularly in Restrainer's case where you have paths embedded >>> in your XML files - you can't use get_example_path() there. >> Can't you use relative paths there? eg the .xml file contains >> "./foo.dat" (or just "foo.dat") which should search for the data file >> relative to the input xml. Otherwise, either you can't relocate you >> setup or have to always run it from the same directory relative to the >> .xml file, both of which would be very annoying. Or perhaps I'm confused. > > I think you are confused - Elina is already using relative paths (e.g. 'input/foo.xml') but they don't work since the examples are run from the top-level directory - they need to be either 'modules/restrainer/examples/input/foo.xml' or 'build/doc/examples/restrainer/input/foo.xml' either of which would, if hard-coded in the XML, obviously preclude a user from running an installed example. Relative paths aren't relative to other files, of course, but relative to the current working directory (it is possible for Restrainer to have relative paths in the XML files be relative to the directory containing that XML though, I suppose). Indeed, that is what it should be (and is done in other similar files, eg the XCode xml config file). If they are, then we don't have a problem since the script can use the get_example_path to find the xml file and all the data files will be in the same dir as the xml file. The context for finding data files in the xml file is the xml file, not whatever directory the user happens to call things from.

> >> The directory containing the examples isn't necessarily writable (say >> once they are installed), so we have to be careful about any files they >> write. I think it is reasonable to insist that the working directory is >> writeable to produce output, but we could also have the samples write to >> a tmp dir. > > You have to balance the confusion that will ensue if users can't find the example outputs against trying to write output into an unwriteable directory. Since the latter yields a pretty clear error message, it seems preferable to me. Agreed. I don't like the writing to a temp dir, which is why I think being able to run examples from anywhere is a good thing.

On Feb 10, 2010, at 12:22 PM, Ben Webb wrote:

> On 02/10/2010 11:58 AM, Daniel Russel wrote: >> Indeed, that is what it should be (and is done in other similar >> files, eg the XCode xml config file). If they are, then we don't have >> a problem since the script can use the get_example_path to find the >> xml file and all the data files will be in the same dir as the xml >> file. The context for finding data files in the xml file is the xml >> file, not whatever directory the user happens to call things from. > > That pronouncement makes it sound like such behavior is some kind of standard, which it of course is not, I would say it is standard behavior in well designed software, but not some kind of standard :-)