Hello Kay,
Sorry I didn't get to this earlier. I must say I'm impressed by your
work. It's a great thing to have scripting interface for quick
prototyping. Unfortunately I can't test it because the computer I use
for development is nonfunctional.
I find it very nice that you and Thomas think about supporting Python
3. Most of the software out there doesn't care about Python 3 very
much and so packaging for Arch Linux is unnecessarily difficult (Arch
uses Python 3.1 as a default Python version).
On 5 February 2011 12:37, kfj <_...@yahoo.com> wrote:
> On 5 Feb., 12:06, "T. Modes" <thomas.mo...@gmx.de> wrote:
>
>> Commited after some changes.
>> * Don't misuse configure_file for installing files. Use the install
>> command instead.
>
> Okay. I'm just now sure about how to go on about the installing on
> Linux. So far I'm just keeping the python modules and plugins in my
> target directory and put my PYTHONPATH variable to point to it. But
> really, the module should go to the system module path and the plugins
> should live in a dedicated plugin directory. I'd like some feedback on
> the issue, and I certainly don't want to just shove stuff into paths
> outside hugin's tree without due consideration. Would someone of the
> developers working on Linux please comment on the issue?
>
I'd go for
${LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/hugin
>> * Your patch contains a lot a line, where only the line ending were
>> changed. -> Unified
>
> Sorry for that. On Linux, every line ends with a newline character and
> nothing else. I don't know how other line endings made it into my
> code, I'll do my best to avoid this in the future. What standard do
> you use in the hugin repo? Do I have to put in carriage returns?
Hugin uses Unix line endings.
>> * Some changes in your patch were already in the repo. You did not
>> provide a patch against the head of the python branch.
>
> Again, sorry. I'm not sure how this happened. I drew a fresh clone
> once the patch was integrated, then modified that, and finally created
> the patch after a commit. Do I have to do more than that? Should I
> fetch a clean clone just before I patch, carry over my modifications
> to it and make the patch from that?
If I understand that you're doing clone whenewer you want to change
the code? If yes, I suggest following worflow:
1. clone the repository from source forge (only first time)
2. change to branch python_scripting (only first time)
3. "hg pull -u" to update to the newest changeset, if there was a
conflict, run "hg merge"
4. do some work
5. commit, optionally GOTO 3.
6. "hg bundle" or "hg export -r REV…" and send patch/bundle to be integrated
7. GOTO 3
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
