On Mon, Oct 13, 2008 at 11:19 AM, Bruno Postle <[EMAIL PROTECTED]> wrote: > > On Mon 13-Oct-2008 at 02:55 +0200, Tomas Klacko wrote: >> >>I am working on a project that utilizes hugin as one of its use-cases. >>The idea is to distribute the execution of the hugin-generated makefile >>rules among several machines. One of the goals is that the user intervention >>necessary to achieve this should be minimal. At my current state, this means >>editing the hugin-generated makefile. The amount of editing required largely >>depends on whether a shared file system is used or not. > >>All that is necessary here is to substitute the relevant the >>hugin-generated command names. >>Example (using nona, but also implies other commands such as enblend, >>enfuse, ..): >>(makefile contents) >>NONA=nona >> >>(substitution) >>NONA=myRemoteNona > > This isn't necessary, just use the `make -e` parameter to substitute > the variable from the environment: > > make -e NONA=myRemoteNona > > ..or > > export NONA=myRemoteNona > make -e > > This works for any of the variables in the .pto.mk file, for > instance I use enblend-mask instead of enblend like so: > > make -e ENBLEND=enblend-mask NONA=nona-mask
Thanks, this nicely solves my first scenario. >>My intent here would be to avoid the need to edit the makefile. >>Simply: >>- take the ~/.hugin configuration file and set NonaExe to myRemoteNona > > This won't work, the ~/.hugin file is only accessed by the GUI (it > is a wxwidgets thing). ~/.hugin stores the configuration for the wxwidgets? (with some values being editable (like actualPath) and some values being constants (like NonaExe)) >>2) When shared filesystem is not used then, obviously, input and output >>files have to be copied among machines during the execution of a >>particular rule. >>It is therefore not sufficient to simply substitute the relevant >>hugin-generated command >>names as in the first scenario. Basically, I have to edit the makefile >>rules so that >>my substitute commands (like myRemoteNona) receive all the necessary >>input file names >>on the command like before the actual arguments (like arguments to nona). > > This shouldn't be a problem, hugin doesn't save the full paths in > the .pto file (other tools do, but you can use ptopath from > Panotools::Script to strip them). So you can regenerate the .pto.mk > Makefile for your remote machine from the .pto file using pto2mk. ptopath and pto2mk a very handy to strip the absolute path. > ..but also I recommend looking at other solutions to your problem, > such as distmake: > > http://sourceforge.net/projects/distmake I would like to compare it to my project, but I failed so far to find any documentation about it (other than source code). The project file contains all the input files (the photos to be stitched). nona complains and refuses to work when some input photo is not present. Example, makefile rule: 974-1-975-10001.tif: 975-1.jpg $(PROJECT_FILE) $(NONA) $(NONA_LDR_REMAPPED_COMP) -r ldr -m TIFF_m -o $(LDR_REMAPPED_PREFIX_SHELL) -i 1 $(PROJECT_FILE_SHELL) There are two input files 974-1.jpg and 975-1.jpg. The rule specifies how to build 974-1-975-10001.tif from 975-1.jpg and the project file. But it will fail if 974-1.jpg is not present (nona will complain), which I assume will not be on a remote machine that will be assigned to execute the rule by distmake. I probably could set NONA to "myRemoteNona $< --", but it will fail for the above reason. Tomas Klacko --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
