Hi Bruno,
2009/10/7 Bruno Postle <br...@postle.net>:
>
> On Wed 07-Oct-2009 at 15:04 +0200, Lukáš Jirkovský wrote:
>>
>>What I think may be quite nice way to store necessary data is the XML.
>>Although I'm not a huge XML fan (in fact I think it's overused) it
>>could bring some improvements to the current workflow. I've two ideas
>>how it could help. First it wouldn't break just because someone used =
>>(or so) in file name. Second it would allow to create better
>>structured files which would be more readable especially when working
>>with stacks.
>
> That would be recreating 'make' with XML and this would be a massive
> task. I think the Makefiles themselves are fine and `make`
> processes them efficiently, what is problematic is the way they are
> assembled in PanoramaMakefileExport, basically we just print
> low-level strings to the Makefile like this:
>
> o << "$(HDR_STACK_" << i << ") : $(HDR_STACK_" << i << "_INPUT)" << endl
>
> I think this could be much cleaner, and as a result the code would
> more closely resemble the intent rather than being a huge list of
> low level string handling.
It could. Currently it's huge mess with some never-used options (like
switches foe different blend apps).
>
> I know I'm not great at this stuff, but in the panostart tool there
> is a perl module that abstacts all the business of writing and
> escaping Makefile rules, i.e. you declare your intent with a list of
> input files, a list of output files, and the command(s) needed to
> generate those output files:
>
> my $rule = new File::Makefile::Rule;
> $rule->Prerequisites ('file-A');
> $rule->Targets ('file-B');
> $rule->Command ('cp', 'file-A', 'file-B');
>
> To turn this into valid, properly escaped and tabbed make-speak you
> just do this:
>
> $rule->Assemble;
Yep, it's much cleaner. But I think this would be much more easy to
implement with XML or other markup language (eg YAML).
>
> Aside from removing the low level stuff, the best thing about
> abstracting it like this is that the module is testable, just feed
> it a bunch of problematic filenames and see if the Makefile succeeds.
>
> --
> Bruno
>
It's not that difficult to test it with Makefile itself, but it's hand work.
2009/10/8 Bruno Postle <br...@postle.net>:
>
> On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote:
>>Lukáš Jirkovský wrote:
>>> What I think may be quite nice way to store necessary data is the XML.
>>
>>this has been discussed before. The result was that some people favor
>>the Makefile, others would favor the XML (me included).
>
> This all sounds like 'version 2 syndrome'. Isn't there enough stuff
> that really needs fixing in Hugin? Sure the .pto format would be
> more elegant rewritten in YAML (or maybe XML), but without any
> positive benefits it is just an opportunity to introduce new bugs.
>
> What can you do with XML that we can't already do with the current
> .pto format?
I'd keep .pto format at least for storing image positions etc. But
with XML it would be much easier to store more informations to store.
I can think of storing informations about positions, stacks, it would
be possible to store informations about exposure and I'm sure that
others could think of may different informations to store.
>
> Abandoning 'make' is a mistake, the Makefile stitching system is
> very powerful: we get ordering of commands, parallel processing,
> restarting, and supervision of the whole process by a mature tool.
> I can't accept "Makefiles are hard" as a valid reason for recreating
> 'make' in XML.
It is powerful but it's not suited for use with GUI application. When
you use it for building some application you can easily avoid
dangerous files names and options. We can't do this here without
limiting users.
>
> --
> Bruno
>
> >
>
Lukas
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
