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.
On 13.04.2012, at 13:14, Harry van der Wolf wrote:
> 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.)
Even if it has been an unanimous decision of the builder community, you would have my vote from the user community. Dropping support (for the bleeding edge version of hugin) for an OS that has no official support since 2007 doesn't really hurt the community i think. And once again: thanks for building hugin on the mac and giving us fresh builds to try out. Do it in your pace, I'm more than happy with it. Habi
On 13 Apr., 13:14, Harry van der Wolf <hvdw...@gmail.com> wrote:
> It also means that my Hugin development environment (currently ~9GB) will
> shrink about 30% and that the bundles will shrink about 30% in size.
Just a thought: maybe it is also a good opportunity to look again into
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.
Op 14 april 2012 13:14 schreef kfj <_...@yahoo.com> het volgende:
> On 13 Apr., 13:14, Harry van der Wolf <hvdw...@gmail.com> wrote:
> > It also means that my Hugin development environment (currently ~9GB) will > > shrink about 30% and that the bundles will shrink about 30% in size.
> Just a thought: maybe it is also a good opportunity to look again into > 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
:)
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).
On 14 Apr., 13:42, Harry van der Wolf <hvdw...@gmail.com> wrote:
> 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.
:) to you!
> 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).
I wasn't aware of this. So this means you had an hsi-enabled hugin
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.
> On 14 Apr., 13:42, Harry van der Wolf <hvdw...@gmail.com> wrote:
> > 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.
> :) to you!
> > 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).
> I wasn't aware of this. So this means you had an hsi-enabled hugin > 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.
I propose to make it the default. CMakeLists.txt:311 --> OPTION(BUILD_HSI "Python Scripting Interface" ON)
> 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?
-- "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
> 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?
Thanks for your comments. Your arguments are also literally the exact reason for the bundled Hugin app as it is delivered now. For a "python enabled" Hugin, swig is needed and it needs to be compiled versus a python version. Then hugin needs to be compiled against that same python and swig version to make it work. And that might work on my system but it's not portable to other systems. Every OSX comes with it's own python version. Sometimes as ppc/i386, sometimes as ppc/i386/x86_64 and lately as i386/x86_64, and between version 2.4, 2.5, 2.6 and 2.7. And that's by Apple itself. The same "Apple certified" official builds can be downloaded from python.org, like you mentioned. These versions are somewhat newer: 2.7.3 and 3.2.3. These argument are on the other hand also true for other libraries and binaries, which are compiled normally for a certain version and architecture, but in this bundle as universal "linked to each other and against each other". That's exactly why we make the bundles: to make it "stand alone portable" apps. If I build a python enabled version, it will literally include python and swig inside the bundle to make the bundle again a "portable stand alone" application like the current bundles, be it without python.
If I can't make that work, we might need to search for another option.
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.
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
> volgende:
> > Hi Harry
> > 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?
> Thanks for your comments.
> Your arguments are also literally the exact reason for the bundled Hugin
> app as it is delivered now.
> For a "python enabled" Hugin, swig is needed and it needs to be compiled
> versus a python version. Then hugin needs to be compiled against that same
> python and swig version to make it work. And that might work on my system
> but it's not portable to other systems.
> Every OSX comes with it's own python version. Sometimes as ppc/i386,
> sometimes as ppc/i386/x86_64 and lately as i386/x86_64, and between version
> 2.4, 2.5, 2.6 and 2.7. And that's by Apple itself. The same "Apple
> certified" official builds can be downloaded from python.org, like you
> mentioned. These versions are somewhat newer: 2.7.3 and 3.2.3.
> These argument are on the other hand also true for other libraries and
> binaries, which are compiled normally for a certain version and
> architecture, but in this bundle as universal "linked to each other and
> against each other".
> That's exactly why we make the bundles: to make it "stand alone portable"
> apps.
> If I build a python enabled version, it will literally include python and
> swig inside the bundle to make the bundle again a "portable stand alone"
> application like the current bundles, be it without python.
> If I can't make that work, we might need to search for another option.
On Mon 16-Apr-2012 at 13:07 -0700, 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. 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:
> 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.
> 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 >> volgende:
>>> Hi Harry
>>> 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?
>> Thanks for your comments. >> Your arguments are also literally the exact reason for the bundled Hugin >> app as it is delivered now. >> For a "python enabled" Hugin, swig is needed and it needs to be compiled >> versus a python version. Then hugin needs to be compiled against that same >> python and swig version to make it work. And that might work on my system >> but it's not portable to other systems. >> Every OSX comes with it's own python version. Sometimes as ppc/i386, >> sometimes as ppc/i386/x86_64 and lately as i386/x86_64, and between version >> 2.4, 2.5, 2.6 and 2.7. And that's by Apple itself. The same "Apple >> certified" official builds can be downloaded from python.org, like you >> mentioned. These versions are somewhat newer: 2.7.3 and 3.2.3. >> These argument are on the other hand also true for other libraries and >> binaries, which are compiled normally for a certain version and >> architecture, but in this bundle as universal "linked to each other and >> against each other". >> That's exactly why we make the bundles: to make it "stand alone portable" >> apps. >> If I build a python enabled version, it will literally include python and >> swig inside the bundle to make the bundle again a "portable stand alone" >> application like the current bundles, be it without python.
>> If I can't make that work, we might need to search for another option.
>> Harry
-- In theory there is no difference between theory and practice. In practice there is.
A few remarks on the python interface and hugin on non-***ix
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.
