Richard Heck wrote: > That's the approach I'm now taking, more or less, as Enrico found yet > further problems. He also suggested a simpler way, namely: note the time > when we start the conversion; then look at the modification times of the > files after the conversion to see which ones got generated. There could > be an issue if the converter runs really fast,
I don't think so. Modification times are stored with a very fine precision (at least on ext3, but I don't believe that it is special here). > so I'll probably end up > also having to keep a simple list of what files were there in the first > place. In any event, the idea is then to have convert() return the list > of generated files as a vector<FileName> (thus implementing an earlier > suggestion of yours, though more generally), and the Exporter can do > with that list as it will. This is indeed simpler, since if we copy > everything to the new tempdir, then we still need to know what we put > there and what the converter put there, and of course it's possible the > converter will over-write some of the files we put there, which may then > need to be copied back to the tempdir for the next converter to use, so > we need to check the modification times anyway. That sounds very complicated. Do usetempdir converters really need to be supported in the middle of the conversion chain? AFAIK we are only talking about html converters here, and those occur only at the end, so it would be enough to simply copy the whole directory (and issue some warnign if such a converter is used elsewhere). That directory will for sure contain too many files, but it is impossible anyway to tell which generated files are needed wnd which are not needed, so it is IMHO no problem if some files like the aux files are in the directory that is finally copied. > There is an issue here about the copiers, since they expect to get a > single file to play with. Almost. It is assumed that there is a single 'main' file, and that all other needed files can be deduced from the main file. Those other files are not copied, though, the copiers only adjust the paths in the main file. If you really want to support usetempdir converters in the middle of a conversion chain then it gets indeed really complicated. How do you know which files to copy back from the new temp dir and which not? I don't believe that the approach based on modification times will work. For example, if the converter modifies the .aux file I don't think it should be copied back, because it would not correspond to the .dvi file in the main temp dir. > (At this point, it seems pretty obvious this > won't make 1.5.0, by the way. This was supposed to be a lot simpler! And > there are other bugs to fix that are more pressing.) Files with the > right extension can be passed to the copier for the relevant format. But > other generated files---e.g., png's in the case of htlatex---would need > either just to be copied directly or passed to copier for some format > associated with that extension. Copiers are _not_ associated to extensions, but to formats. Extensions do not matter at all in LyX. What matters is the format. Extensions are only used to suggest defaults in file dialog, and as a last resort if the format of a file cannot be determined from the contents (but this is done in utility code one never needs to call directly). If you don't know the format of a file, use formats.getFormatFromFile(filename) and don't care about extensions. > I think the former may be enough, as > "associated files" will probably not be the kinds of files that need > internal stuff changed, though they could be, in principle. Thoughts? IMHO you don't need to make assumptions which files will have copiers and which will not, see above. Georg
