Uwe Stöhr wrote: > Am 03.12.2015 um 21:57 schrieb Georg Baum: > >>> The system for saving relative paths, etc, seems a bit...delicate. >> >> Maybe, maybe not (so far only Uwe saw this). > > Also others have this problem as well, see e.g. Kornel's commits: > http://www.lyx.org/trac/changeset/d879599cec4902a1a3ea7aa7a8d7d24815701036/lyxgit > or > http://www.lyx.org/trac/changeset/42536a561606290ebdb90c46badbb451487f5293/lyxgit
None of these did change a path. >> One thing is clear however: Files with \origin /systemlyxdir/doc/ must be >> edited with a LyX binary that belongs to the directory where the file is >> located: > > Why is this clever? clear, not clever. > I don't see the benefit. There is no reason in my > opinion that the path is changed because all dependencies of the file > are existent and correct. So there is no obvious reason why the relative > paths are automatically converted to absolute ones. I was now able to reproduce the changed paths. According to http://www.lyx.org/trac/ticket/9815 this works as designed: If a document contains a valid \origin tag, then all relative paths are changed to absolute ones constructed from \origin on saving. This is in general the wanted behaviour (and the reason for having \origin at all), except for one case: Editing LyX documentation in a directory which is not the system dirctory as determined by the Package class in src/support. In this case, the \origin machinery assumes that the user did copy the doc to some other location, and that he wants to keep it separate from the LyX installation. This assumption is wrong if one edits the docs in the source tree, and I agree that something needs to be done for this case. Unfortunately I am not sure what to do. Here are the alternatives I can imagine: - Set \origin to unavailable for all docs in the sources. This would be easy to do, but also mean that we need to change it during installation (which is currently only implemented for autotools, not in cmake and not in the windows installer) - Implement some heuristic to recognize if docs in a LyX in lib/doc directory of a source tree are edited, and do not change paths if that is the case. Not very transparent for the user, and strange things can happen if the heuristic is wrong. - Do not change the paths in general if the files can be found using the relative paths. Has the additional benefit that this is also the wanted behaviour if I copy a whole directory of LyX files (including referenced graphics) to a new location. Disadvantage would be that the machinery does now depend on the presence of external files, and it is not guaranteed that the file that is found is the correct one. Are there other possible solutions? I prefer the last one, since it does not get into the way of people who know what they are doing and copy a LyX file including all needed dependencies. The current solution punishes these people by requiring them to repair the incorrectly changed paths by hand, or by forcing them to disallow setting \origin in the preferences (but the latter does not work if you receive files from collaborators which have \origin set). >> Uwe says he cannot run LyX from the build dir. I believe that this is a >> major time sink (installation is needed for testing a tiny source change, >> using the debugger is not possible etc), and I offered my help for >> investigation, but so far he did not want to investigate why running from >> the build dir does not work. > > That is not true. I know why this doesn't work. That is why the > installer exists: you need to specify the PATH variable linking to Perl > (e.g for texindy), Python (for our scripts), ImageMagick which needs > also Ghostscript, rsvg and/or Inkscape. If this is the only issue then you can run LyX from within MSVC easily: You can specify environment variables for debugging in MSVC, so you can set the correct PATH once in MSVC and then save a lot of time by not requiring installation for each tiny source change. I don't know by heart how to do it, but I can look it up if you want. Georg
