[OSX] Dropping support for Hugin on Mac OS X 10.4 (Tiger) and PCC hardware
Harry van der Wolf
From the title you can already deduce what this is about.
As you might have seen from the downloads from my statistics webpage (1): Tiger as OS and PPC as hardware platform are disappearing.
You see the following as of 01 January 2012 on a total of 475 downloads:
- only 0.4 % is for the Tiger 10.4.x release (2 downloads out of 475)
- 2.1% is for the PPC hardware architecture (10 downloads).
- Mac OS X Leopard (10.5.x) is dropping below 5%.
For me this is the moment to stop supporting both Tiger and PPC.
Tiger is already 3 releases back (with the fourth release (Mountain Lion) coming in July) and not actively supported anymore by Apple since end of 2007 and not at all as of 2009 (appart from the existing knowledge base). Even Leopard is by now a beast "threatened with extinction".
From now on I will only build for Leopard (10.5.x) and newer and only for intel (32bits and 64bits).
This also means that the last official build that supports both Tiger and PPC is the 2011.4.0 bundle.
It also means that my Hugin development environment (currently ~9GB) will shrink about 30% and that the bundles will shrink about 30% in size.
I realize that this is not a democratic decision at all but so be it. (On the other hand: I'm the only mac builder right now. Therefore, the "mac builder community" unanimously decided this.)
I'm currently trying to implement the lensfun functionality, that Thomas introduced, into the bundle. That requires an annoying amount of other dependency libraries.
I'm not as motivated anymore as I used to be so I troubleshoot/build on a much slower pace. You will see a new development build when it's ready.
When that's done I will start to identify and (sort of) document the Mac ppc code inside hugin so that it can be removed when the community thinks it's time to do so.
Hoi,
Harry
(1): <http://panorama.dyndns.org/macoverview.php>
--
Hugin development bundles for Mac OS X
ImageFuser for Mac OS X
KImageFuser for Linux
David Haberthür
I realize that this is not a democratic decision at all but so be it. (On the other hand: I'm the only mac builder right now. Therefore, the "mac builder community" unanimously decided this.)
kfj
> It also means that my Hugin development environment (currently ~9GB) will
> shrink about 30% and that the bundles will shrink about 30% in size.
compiling the python interface on the mac platform. Together with the
code to support the old systems, whatever it was that kept you from
succeeding in building hsi-enabled hugin for macs may have gone away.
Kay
Harry van der Wolf
--
kfj
> I already downloaded and installed both python 2.7.3 and 3.2.3 yesterday
> for i386/x86_64. The "old" 2.7.2 and 3.2.x were for i386/ppc.
> So I had it on my list but as I had so much trouble in the past I didn't
> want to mention it.
> However (and I mentioned this before): When building a "linux like" Hugin
> simply with cmake, the python plugin structure works fine.
> The big issue is the universal bundle with python in it (or not currently).
running on a mac and using python plugins? That would be much more
than I thought (I thought it never ran at all)
Happy bundling. Hope it works out this time... it's really frustrating
how hsi/hpi seems to compile and run just fine on all platforms, but
so far there's only a few linux packages containing it.
Kay
Kornel Benko
I propose to make it the default.
CMakeLists.txt:311
--> OPTION(BUILD_HSI "Python Scripting Interface" ON)
> Kay
>
Kornel
Stefan Peter
On 04/14/2012 01:42 PM, Harry van der Wolf wrote:
>
> However (and I mentioned this before): When building a "linux like"
> Hugin simply with cmake, the python plugin structure works fine.
> The big issue is the universal bundle with python in it (or not currently).
Please forgive my ignorance when it comes to packaging for apple OS, but
bundling the complete python stuff with hugin seems at least
questionable to me.
What happens if the users already has a python interpreter installed?
Are you aware that you may have to provide (security) updates and
support for the python part as well? How many different python flavors
and versions may end up on a mac with multiple applications installed
that use python if all packagers bundle their own version?
Shouldn't it be be possible to state something like "If you want to use
the python plugins (highly recommended, by the way), please make sure a
python package is installed. I recommend ..." in the hugin bundle?
I'm sure you know that there are official python builds for the mac at
http://www.python.org/getit/mac/.
Just my 2 cents.
Regards
Stefan Peter
--
"In summary, I think you are trying to solve a problem that may not
need to be solved, using a tool that is not meant to solve it, without
understanding what is causing your problems and without knowing how
the tool actually works in the first place :)"
Jeffrey J. Kosowsky on the backuppc mailing list
Harry van der Wolf
Please forgive my ignorance when it comes to packaging for apple OS, but
bundling the complete python stuff with hugin seems at least
questionable to me.
What happens if the users already has a python interpreter installed?
Are you aware that you may have to provide (security) updates and
support for the python part as well? How many different python flavors
and versions may end up on a mac with multiple applications installed
that use python if all packagers bundle their own version?
Shouldn't it be be possible to state something like "If you want to use
the python plugins (highly recommended, by the way), please make sure a
python package is installed. I recommend ..." in the hugin bundle?
I'm sure you know that there are official python builds for the mac at
http://www.python.org/getit/mac/.
Just my 2 cents.
Regards
Stefan Peter
Tom Sharpless
If you want Hugin to remain viable on Windows and OSX, you must
discipline your use of packages that assume the Linux "build it
yourself locally" philosophy. That is simply not an option for Win
and Mac users, so we have to rely on really heroic efforts by builders
like Harry and Matt Petroff. Make life too hard for those guys, and
Hugin becomes a Linux-only sandbox toy.
I myself stopped building for Windows sometime last year because it
had just gotten too hard to maintain a working build environment --
and that was before the Python adventure. I don't know if it is too
late to reverse this trend, but I do think it would be possible, with
some thought about cross-platform issues, to resolve many of the
current difficulties and prevent many new ones from arising.
-- Tom
On Apr 15, 4:12 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Op 15 april 2012 13:10 schreef Stefan Peter <s_pe...@swissonline.ch> het
Bruno Postle
>This thread should be a wake-up call for Hugin's developers.
>
>If you want Hugin to remain viable on Windows and OSX, you must
>discipline your use of packages that assume the Linux "build it
>yourself locally" philosophy. That is simply not an option for Win
>and Mac users, so we have to rely on really heroic efforts by builders
>like Harry and Matt Petroff. Make life too hard for those guys, and
>Hugin becomes a Linux-only sandbox toy.
Though I think most of the recent Hugin code was written on Windows
by the other Thomas.
Hugin does build easily on Linux, but partly because people spend
the time to fix the Linux distributions. It took six months to get
tclap into fedora so we can remove that code from Hugin:
https://bugzilla.redhat.com/show_bug.cgi?id=683591 and I'm sure you
will find similar stories in other Linux distributions. It may seem
like Hugin has been created for Linux, but it's also kind-of the
other way around.
>I myself stopped building for Windows sometime last year because it
>had just gotten too hard to maintain a working build environment --
>and that was before the Python adventure.
..but there are so many libraries that could potentially transform
Hugin, it can't all be developed here in isolation:
http://www.wired.com/beyond_the_beyond/2012/04/tech-art-computer-vision-algorithm-implementations/
--
Bruno
Stefan Peter
Sorry, but I have to disagree:
On 16.04.2012 22:07, Tom Sharpless wrote:
> This thread should be a wake-up call for Hugin's developers.
>
> If you want Hugin to remain viable on Windows and OSX, you must
> discipline your use of packages that assume the Linux "build it
> yourself locally" philosophy.
The stable Hugin releases have been part of every mature linux distro I
know. There is no reason to "build it yourself locally" unless you
a) want to live on the bleeding edge of technology and
b) your distro does not supply you with nightly builds
That is simply not an option for Win
> and Mac users, so we have to rely on really heroic efforts by builders
> like Harry and Matt Petroff.
I agree: Kudos to Harry and Matt for their effort to supply Mac/Win
users with recent Hugin versions. I have coded for both platforms and I
know how different OSes are and what hurdles you have to jump in order
to make IT work.
Make life too hard for those guys, and
> Hugin becomes a Linux-only sandbox toy.
This is the part I can not agree: There are plenty of solutions for
creating panoramas for other operating systems than linux/BSD/***ix ...
Yes, you will have to pay for those, but you paid for the OS, too, so
what? Why should Hugin care for the least common denominator? Where is
my CP/M Hugin for my Rainbow 100?
Don't get me wrong: I'm not proposing that the Hugin development should
abandon mac or windows (or whatever other operating systems one may be
porting Hugin to). But neither should the development be restrict to the
limitations posed by non ***ix operating systems. Harry is doing it
exactly right: he tries to make it happen, getting official OS support
or not does not matter. And I'm quite sure that there is a way to get
python scripting for windows users, too: After all, TheGimp did it for
years, did he not?
> I myself stopped building for Windows sometime last year because it
> had just gotten too hard to maintain a working build environment --
> and that was before the Python adventure.
There are other FOSS projects that have jumped this hurdle, so it is
possible to do so. There is no reason to put our collective head into a
bucket: there are ways to overcome the limitations imposed upon us by
the operating systems.
One solution for windows that comes to mind is mingw[1] or mingw-64[2].
Another is cygwin[3] and there is mingw-cross-env [4], too. I have no
pointers for MacOS, but given the fact that MacOS is based on some BSD
derivate (IIRC), the differences to a ***ix should not be so grave as it
is in the win side.
> I don't know if it is too
> late to reverse this trend, but I do think it would be possible, with
> some thought about cross-platform issues, to resolve many of the
> current difficulties and prevent many new ones from arising.
>
Tom, please don't try to stand in the way of the technical advance. You
are doing a tremendous amount of work for the development and the
support of Hugin and your know-how and expertise in these areas is
invaluable. Your concerns regarding the integration of features like the
python scripting interface are very valid, but this will drive the
development and sooner or later, it will be integrated in the
distributions and solved to everyones satisfaction. If not, this egress
was an evolutionary death end and we will see a lua/perl/wsh solution
sooner or later.
With kind regards
Stefan Peter
[1]http://www.mingw.org/
[2]http://mingw-w64.sourceforge.net/
[3]http://www.cygwin.com/
[4]http://mxe.cc/
--
In theory there is no difference between theory and practice. In
practice there is.
kfj
platforms:
To run a python-enabled hugin, swig is not needed. Swig is only needed
to create the python module which gives python access to hugin's
functionality. The python module is simply a shared library which can
be distributed as-is.
To run python-enabled hugin on a Linux machine, AFAIK (Linux machines
always have python anyway) python isn't necessary. I've written the
python interface so that it is only activated and initialized when the
first call to it happens. So if python isn't there, hugin will run
just fine, but trying to use python plugins will simply not work. On
MacOS this should be the same. On Windows, the story is probably
different:
AFAIK, on Windows, all of hugin is linked statically. So I suppose the
idea is that the shared library which constitutes the python module
also has to be statically linked-in somehow. This is wrong. The python
module is loaded by python when the need arises (like, a plugin is
called). It may be though that trying to link everything statically
also results in the python interpreter being statically linked to
hugin (I'm not sure if or how this is done). I see no reason why this
should be done, but on the other hand it's no big deal, since python
is made to allow for such behaviour as well.
I think the fixation on statically linking hugin with everything and
using MSVC for the process is part of the problem. If you look at
hugin as a ***ix-born program (is it?), MSVC is alien territory. Using
MinGW would be much more appropriate, and then, along with using
MinGW, all the libraries could be linked dynamically, just as on
***ix. The static linking comes, I think, from a specific notion:
'DLL hell', the problem that arisies from the fact that on Windows
there seems to be confusion about where shared libraries should live,
and from the fact that Windows doesn't have package management. I've
heard that these issues have been adressed to some extent and the
situation is much better now than it was a few years back, but the old
fears still persist.
So static linking and using MSVC becam the norm. The code is full of
ugly conditional compiles and make directives which reflect the
wrestling with WIndows'/MSVC's alien nature. From my (limited)
experience with the code I would say that they often are expressed
along the lines of '#ifdef Windows', rather than saying that they are
for the specific 'statically linked+MSVC' combination. So if anyone
tried to do the sane thing and use MinGW to create a dynamically-
linked hugin using precisely the same tools which are used on ***ix,
they would still be building for a Windows system, '#ifdef Windows'
would be true, and the conditionals meant for statically-linked+MSVC
hugin would fire, bending the code so that compiling a dynamically-
linked+MinGW hugin is bound to fail.
What to do? Someone with intimate knowledge of the code would have to
go through the whole thing with a fine tooth comb to set things right.
I doubt there is anyone willing to do that, after all the statically-
linked+MSVC product works.
I wonder: is there anyone (Thomas?) who has compiled an hsi module on
Windows and would be willing to share it? Hsi is useful in itself, as
it allows most of hugin's backend functionality to be used from
python. The first step would be to try if and how this module works
(or fails) on other Windows machines and what is really required to
get it to run there. Then the next step would be to try out a python-
enabled hugin to see if it can run on a system without python. I will
not compile hugin on Windows myself, but I'll gladly test someone
else's hsi module and python-enabled hugin on my Windows systems if
this can help advance the cause of my brainchild. I can't help with
MacOS, though.
Kay