On 5 Feb., 13:10, Lukáš Jirkovský <[email protected]> wrote:
> Hello Kay,
> Sorry I didn't get to this earlier. I must say I'm impressed by your
> work.
Thank you. I feel flattered ;-)
> 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.
Hope you're up and running soon. So far I think that Thomas has been
the only one touching the new branch, and I'd wish for more feedback
and better integration with hugin.
> 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).
If I understand the workings of the cmake code rightly, it will build
the appropriate code for whatever Python it finds libraries for. So if
your system has 3.X, the module should be 3.X as well. SWIG generates
code that is universally compatible. This approach is wise, since on
Linux Python and the OS are quite intimately interwoven, and you might
as well just go for the type of module that works with your default
version. Indeed I haven't given much thought to the possibility of
compiling it to use 3.X on my system, even though I'm sure cmake can
be made to do so.
> I'd go for
> ${LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/hugin
I'll give that a shot, and if it works nicely I'll recommend it for
general use.
> Hugin uses Unix line endings.
Fine. I thought so. You know, if you edit stuff on Windows, it sneaks
those silly carriage returns in before you know it... Some editors do
at least allow you to keep them out or do so automatically when the
input is UNIX style.
> 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
I do it slightly differently: I have a direct clone of the SF repo,
which I keep clean and only get to the latest standard by doing
cd hugin.hg
hg pull
hg up
in it's root directory. I need that branch to have a build of the
latest default branch handy for testing and for reference. Once I have
the latest changes, I clone the clean clone to a working version, say
cd ..
hg clone hugin.hg work.hg
cd work.hg
Then I update to the python_scripting branch
hg up -C python_scripting
since I do that just after my last patch has been inserted, I now have
the status quo, as applied by the insertor of the patch. Now I work on
this body of code until I'm satisfied. Then I commit and generate the
patch:
hg commit
hg export XXXX > patchXXXX
gzip patchXXXX
and put the patch online in my bazaar repo to be picked up.
I thought that even if someone else also modifies the branch in the SF
repo, since my patch only contains a single changeset's worth, and
only has one ancestor, since I don't merge anything, using hg export
would be the adequate mechanism. Please correct me if I'm doing it
wrongly.
Kay
--
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
