Hi Thomas! Thanks for your explanations.
On 2 Apr., 16:53, "T. Modes" <thomas.mo...@gmx.de> wrote: > No, that was not the indention. We want to keep the make file approach > for stitching. The make file is created in > PanoramaMakefileExport::createMakefile. But this method mixes > stitching logic with make file syntax. Ok, but may I ask whats the main reason for using make here? It obviously causes trouble with escaping and quoting. Is any special make feature used, like dependencies, and changed files detection ..? Some rules depend on each other, in the generated makefile. But is it important to rebuild only files with changed dependencies? Or is it more like a static script invoking one tool after the other? At least the output of a make run looks like this, but i haven't looked at every line in detail. For example if you use make to run cp detectors, the generated data is part of the pto file, afaik. In that case, make has nothing to use as a generated file for that rule and check it's timestamp. But of course make is a well established tool, and it allows easy batch processing once the makefile is generated. So the parts of the project idea would be: - develop/port an object oriented abstraction of all the items existing in a makefile, similar to bruno's pearl scripts. With the goal to have a bulletproof makefile generation lib, and never have to fight with quoting/escaping and other flaws again. - transfer cp detection to using make, which makes it "batch-able". - use cp detectors and image metadata to autodetect complex panoramas (or is that already somewhere?) - Extend PTBatcherGUI do handle those new batch jobs. (I think it already queues makefiles, doesn't it for batch stitching?) Am I right? > I tested also your second exercise. It works good. But some comment: > your approach will fail if the project filename or image filename > contains special characters (like # or : and other). Therefor the > filenames need to be escaped or quoted. This could be easily done > using some variables and in the target only using this variables. mhm, I think in my case it's not that critical, because the filenames are only arguments to echo, not used directly in the makefile. So a # wouldn't trigger a comment. But a \ would be critical. And there are always surprises with quoting, according to my experience :).. > Now concentrate better on your proposal. I hope I have give you an > overview with my above descriptions. Yes, that should be done soon. I'm not sure, what the proposal exactly should look like. I'm working on a draft. I'll discuss it with you. Flo -- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx To unsubscribe, reply using "remove me" as the subject.
