OSX supported platforms
Yuv
thanks to all contributors that are advancing the OSX version of
hugin.
If I understand correctly, supporting both PPC and Intel architectures
is adding complexity to the task, and for both there is a 32bit and a
64bit version.
How would the contributors and tester feel about focusing on one of
the four potential combinations, and add the other three progressively
later on when the build for the first target combination is solid?
Yuv
Harry van der Wolf
I'm focusing on a straight macports route and a cmake universal build
for ppc and i386, which should run on every system but does not fully
utilize the new IA64 systems.
After a very busy last 10 days and some wxwindows problems on my
system, I'm now back on the cmake track for a standard compilation on
mac with macports (and Rob Campbell reported an almost 100%
successful run with Fink, apart from localisation)
At this moment I'm just starting on the final step, which is the
localisation for hugin on the mac. On the Mac, xrc/data/help_LOCALE
should be in the bundle as LOCALE.lproj/help. At this moment that
does not work. Ippei wrote a shell script for that via his Xcode
route. I need to do some modifications to that script and add a
ADD_CUSTOM_COMMAND to one of the CMakeModules to get that working.
Off course it would be better to to that directly from source but I'm
not a programmer. I think it worked from the " old" (auto)make route
as the older beta's and 0.6 had it in place. It is mentioned in src/
hugin/MainFrame.cpp still in the 0.7 beta 4, but I did not check that
yet. (weekend just started, finally some time).
At the same time I'm working on Peter Crowley's cmakemodule
AppleRELEASEOptions.cmake and script PackageMacAppBundleLibs.sh.in to
build a complete portable bundle. (portable bundle means here: a
bundle with all libs and binaries in it either for one architecture:
straight run from Fink/Macports, or a universal bundle: partly
macports/fink).
I've changed the default behaviour of AppleRELEASEOptions.cmake as
it copied to and worked from /usr/local/bin which required sudo
rights for both the cmake and make step. It now operates from
hugin_BINARY_DIR. The only sudo command now is "sudo make install".
I added enfuse and hugin_stitch_project to the bundle. As soon as I'm
finished I will send the patch to the mailing list.
So, to answer your question: "How would the contributors and tester
feel about focusing on one of the four potential combinations, and
add the other three progressively later on when the build for the
first target combination is solid?"
At this moment I have already two parallel build tree's for cmake:
standard macports and universal macports/manual (and off course
Ippei's Xcode route).
I can build an i386 via macports, an i386 and ppc via universal
macports/manual only by exporting a pkgconfig and some CFLAGS/
CXXFLAGS settings.
Only the localisation need to be fixed, than it is ready (AFAIK).
Hoi,
Harry
Ippei UKAI
On 2008-01-12, at 00:35, Yuv wrote:
> If I understand correctly, supporting both PPC and Intel architectures
> is adding complexity to the task, and for both there is a 32bit and a
> 64bit version.
Yes, and no. 'Supporting' both PPC and i386 architectures adds
complexity, so does 'supporting' any one architecture. I don't think
having two architectures for one platform isn't adding much
complexity development-wise. I rarely had architecture specific bugs
once crosscompilation setup established.
Said that, the effort to get hugin work on either native architecture
and to build self-contained universal binary with cross-compilation
are very different tasks.
> How would the contributors and tester feel about focusing on one of
> the four potential combinations, and add the other three progressively
> later on when the build for the first target combination is solid?
One of two as we are not touching 64bit architectures yet for the
reason precisely you are pointing out. But that stands only because
64bit is an optional feature; 64bit Mac runs 32bit architecture
natively as well.
Either way, I don't think it's plausible to limit architectures for
testing would help in any way. Either native architectures can be
built and tested with CMake build for on site installation and
MacPort/Fink. If we said PPC, it indeed runs on i386 but needs cross
compilation, which is a very different effort, not to mention i386
executables do not run on PPC.
I think we should clearly separate the tasks of:
- making hugin compile and run natively with simple CMake build
supported by Fink/MacPorts, and
- effort towards self-contained release package; CMake or Xcode,
self-build libraries, cross-compilation, resources inside the bundle.
They both have very different problems and wouldn't help us if anyone
got them mixed up. It would be a good idea to separate the threads as
much as possible between those efforts. That way we can also prevent
anyone joining the effort later (or someone like Yuv who wants to
monitor our efforts nevertheless) from being confused by the two
progresses we are making in parallel.
Ippei
--
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei...@mac.com Skype: ippei_ukai
Homepage: http://homepage.mac.com/ippei_ukai/
Ippei UKAI
On 2008-01-12, at 09:17, Harry van der Wolf wrote:
> At this moment I'm just starting on the final step, which is the
> localisation for hugin on the mac. On the Mac, xrc/data/help_LOCALE
> should be in the bundle as LOCALE.lproj/help. At this moment that
> does not work. Ippei wrote a shell script for that via his Xcode
> route. I need to do some modifications to that script and add a
> ADD_CUSTOM_COMMAND to one of the CMakeModules to get that working.
> Off course it would be better to to that directly from source but I'm
> not a programmer. I think it worked from the " old" (auto)make route
> as the older beta's and 0.6 had it in place. It is mentioned in src/
> hugin/MainFrame.cpp still in the 0.7 beta 4, but I did not check that
> yet. (weekend just started, finally some time).
I think necessity to bundle resources should be categorised as "a
bug" from now on. You are just working around that 'bug' with this.
There are a few such inherent 'bugs'. XRC directory is probably still
assumed inside the bundle only (no fall back to PREFIX/share/hugin).
The language option is disabled because self-contained build uses
OSX's native locale selection mechanism. (We will need
SELF_CONTAINED_RELEASE macro to make some of the options accessible
when not bundled.)
Anyway, the task of building localisation directories for .app bundle
certainly needs be done as a part of release build. It's just that if
you could take a look at few lines in the code that would be really
nice and probably is easier for you too (for now). Most resource
handling happens in huginApp.cpp
> At the same time I'm working on Peter Crowley's cmakemodule
> AppleRELEASEOptions.cmake and script PackageMacAppBundleLibs.sh.in to
> build a complete portable bundle. (portable bundle means here: a
> bundle with all libs and binaries in it either for one architecture:
> straight run from Fink/Macports, or a universal bundle: partly
> macports/fink).
> I've changed the default behaviour of AppleRELEASEOptions.cmake as
> it copied to and worked from /usr/local/bin which required sudo
> rights for both the cmake and make step. It now operates from
> hugin_BINARY_DIR. The only sudo command now is "sudo make install".
> I added enfuse and hugin_stitch_project to the bundle. As soon as I'm
> finished I will send the patch to the mailing list.
I wonder why we need 'sudo' for making release builds. If a bundle is
portable, that shouldn't involve any directories owned by root.
Harry van der Wolf
>
>> At the same time I'm working on Peter Crowley's cmakemodule
>> AppleRELEASEOptions.cmake and script PackageMacAppBundleLibs.sh.in to
>> build a complete portable bundle. (portable bundle means here: a
>> bundle with all libs and binaries in it either for one architecture:
>> straight run from Fink/Macports, or a universal bundle: partly
>> macports/fink).
>> I've changed the default behaviour of AppleRELEASEOptions.cmake as
>> it copied to and worked from /usr/local/bin which required sudo
>> rights for both the cmake and make step. It now operates from
>> hugin_BINARY_DIR. The only sudo command now is "sudo make install".
>> I added enfuse and hugin_stitch_project to the bundle. As soon as I'm
>> finished I will send the patch to the mailing list.
>
> I wonder why we need 'sudo' for making release builds. If a bundle is
> portable, that shouldn't involve any directories owned by root.
>
> Ippei
>
To clarify:
Peter's script needed sudo.
Apart from the xrc localisation bug, the cmake route should build the
following.
- The "my system only" bundle:
The command "cmake ../hugin" builds a "barebone" hugin.app only
containing the hugin binary, icons and localisation. It relies on
shared libraries and binaries "somewhere" in the path, be it: /usr/
local or /opt/local or whatever prefix you use (builder should take
care of his/her own path environment if he/she uses aother prefixes).
- The portable bundle:
To create a portable self-contained bundle, the cmake script must be
called with "cmake -DCMAKE_BUILD_TYPE="Release" ../hugin". The
total build process will then include a step to gather libraries and
binaries and put them in the bundle, by "finding" them using
"otool" (for grabbing necessary libraries) and using
"install_name_tool" to change paths where these libraries/frameworks
should be called from. This script works fine, but needed sudo and
missed two binaries. I already corrected the sudo necessity and the
process no longer needs sudo to be able to create a bundle.
The "sudo make install" remains as it is the unix/linux/BSD way of
installing you compiled binaries, libraries, header files, docs and
manpages to the prefix paths.
Both ways suffer at this moment from the xrc localisation bug as
mentioned.
Pablo d'Angelo
>
> following.
>
> - The "my system only" bundle:
> The command "cmake ../hugin" builds a "barebone" hugin.app only
> containing the hugin binary, icons and localisation. It relies on
> shared libraries and binaries "somewhere" in the path, be it: /usr/
> local or /opt/local or whatever prefix you use (builder should take
> care of his/her own path environment if he/she uses aother prefixes).
Yes, this is good, and once this works reliably, it can be included in fink
or MacPorts easily. I also think that the "portable bundle" is mostly an
extension of this approach (in terms of constructing the Hugin and
HuginStitchProject bundles). It probably makes sense to get this working
really well, and then focus on building the portable bundle.
> Both ways suffer at this moment from the xrc localisation bug as
> mentioned.
I have to admit that I haven't looked at the OSX part of the CMake scripts
much yet, so I don't know how this is done best. Also, the scripts seem
quite complicated, so I haven't touched it. Without a platform
to test my changes on, I fear that I would do more damage than good.
If you can't mess with the CMake files yourself, I can modify the CMake
scripts so that the files are place in the right directories. To do this, I
need a detailed directory/file structure of both the Hugin and the
HuginStitchApp bundle.
ciao
Pablo
Pablo d'Angelo
Harry van der Wolf wrote:
> - The portable bundle:
> To create a portable self-contained bundle, the cmake script must be
> called with "cmake -DCMAKE_BUILD_TYPE="Release" ../hugin".
It would probably make more sense to add a HUGIN_OSX_SELFCONTAINED switch,
instead of reusing the CMAKE_BUILD_TYPE, which is normally used to build
debug vs. release vs release with debug symbols builds.
Btw. what should be done with the command line tools such as fulla
or align_image_stack in this case? They are not useable without the
command line, but might be quite useful for other scripts (for example, the
enfuse script Roger Howard wanted to write some time ago).
> The
> total build process will then include a step to gather libraries and
> binaries and put them in the bundle, by "finding" them using
> "otool" (for grabbing necessary libraries) and using
> "install_name_tool" to change paths where these libraries/frameworks
> should be called from. This script works fine, but needed sudo and
> missed two binaries. I already corrected the sudo necessity and the
> process no longer needs sudo to be able to create a bundle.
>
> The "sudo make install" remains as it is the unix/linux/BSD way of
> installing you compiled binaries, libraries, header files, docs and
> manpages to the prefix paths.
For the windows build (which is quite similar to the "portable
self-contained bundle"), I have redefined the CMAKE_INSTALL_PREFIX
to point into a directory of the build tree. It thus won't overwrite
the system installation of hugin. I think such a step might be a good
idea for the self-contained bundle as well.
ciao
Pablo
Harry van der Wolf
Op 12-jan-2008, om 14:35 heeft Pablo d'Angelo het volgende geschreven:
>
> Hi Harry,
>
> Harry van der Wolf wrote:
>> - The portable bundle:
>> To create a portable self-contained bundle, the cmake script must be
>> called with "cmake -DCMAKE_BUILD_TYPE="Release" ../hugin".
>
> It would probably make more sense to add a HUGIN_OSX_SELFCONTAINED
> switch,
> instead of reusing the CMAKE_BUILD_TYPE, which is normally used to
> build
> debug vs. release vs release with debug symbols builds.
>
I agree. It's the way Peter had set it up, but another switch could
also be used.
It's all starts from CMakeLists.txt in src/hugin1/hugin. That's where
the portable self-contained bundle is created.
++++
IF (APPLE)
IF(${CMAKE_BUILD_TYPE} STREQUAL "Release")
INCLUDE (${CMAKE_SOURCE_DIR}/CMakeModules/
AppleRELEASEOptions.cmake)
ENDIF(${CMAKE_BUILD_TYPE} STREQUAL "Release")
+++++
This could be very easily changed to another switch.
This CMakeLists.txt is the same origin for the .xrc actions. Thats
also where I wanted to insert another IF (APPLE).
The hugin bundle needs in Hugin.app/Contents/Resources the
$lang.lproj directories.
The en.lproj directory contains an empty locale directory and a help
directory containing the help files (obvious).
All other $lang.lproj directories only contain a locale directory
with the relevant hugin.mo and wxstd.mo
> Btw. what should be done with the command line tools such as fulla
> or align_image_stack in this case? They are not useable without the
> command line, but might be quite useful for other scripts (for
> example, the
> enfuse script Roger Howard wanted to write some time ago).
I do not exactly know what you mean, but the platypus package (http://
www.sveinbjorn.org/platypus) has quite some options and
possibilities. I have used it before to change command line tools and/
or scripts to MacOSX applications.
But as said: I need to further dive into the fulla and
align_image_stack tool to see hat they are and what they do (although
I can guess it).
>
>> The
>> total build process will then include a step to gather libraries and
>> binaries and put them in the bundle, by "finding" them using
>> "otool" (for grabbing necessary libraries) and using
>> "install_name_tool" to change paths where these libraries/frameworks
>> should be called from. This script works fine, but needed sudo and
>> missed two binaries. I already corrected the sudo necessity and the
>> process no longer needs sudo to be able to create a bundle.
>>
>> The "sudo make install" remains as it is the unix/linux/BSD way of
>> installing you compiled binaries, libraries, header files, docs and
>> manpages to the prefix paths.
>
> For the windows build (which is quite similar to the "portable
> self-contained bundle"), I have redefined the CMAKE_INSTALL_PREFIX
> to point into a directory of the build tree. It thus won't overwrite
> the system installation of hugin. I think such a step might be a good
> idea for the self-contained bundle as well.
Again I fully agree. Should have thought of that myself.
>
> ciao
> Pablo
>
> >
ippei...@mac.com
> Harry van der Wolf wrote:
> > Apart from the xrc localisation bug, the cmake route should build the
> > following.
>
> > - The "my system only" bundle:
> > The command "cmake ../hugin" builds a "barebone" hugin.app only
> > containing the hugin binary, icons and localisation. It relies on
> > shared libraries and binaries "somewhere" in the path, be it: /usr/
> > local or /opt/local or whatever prefix you use (builder should take
> > care of his/her own path environment if he/she uses aother prefixes).
>
> Yes, this is good, and once this works reliably, it can be included in fink
> or MacPorts easily. I also think that the "portable bundle" is mostly an
> extension of this approach (in terms of constructing the Hugin and
> HuginStitchProject bundles). It probably makes sense to get this working
> really well, and then focus on building the portable bundle.
an inherent bug in the code that shouldn't be necessary for in-system
installation.
> > Both ways suffer at this moment from the xrc localisation bug as
> > mentioned.
actually puts xrc inside the bundle. "my system only" definitely needs
a fix in the code that let xrc directory to be installed in the system
(under PREFIX/).
Please note that both need a small patch to some xrc files.
For an ease of development, we probably should stop falling back to
the system directories at once and just if-else with the macro that
specifies portable bundle or not. It's gonna be a hell to debug the
portable bundle having system installation. It's best to treat not
finding resources in the bundle or as specified in the preferences a
fatal error when supposed to be self-contained.
> I have to admit that I haven't looked at the OSX part of the CMake scripts
> much yet, so I don't know how this is done best. Also, the scripts seem
> quite complicated, so I haven't touched it. Without a platform
> to test my changes on, I fear that I would do more damage than good.
>
> If you can't mess with the CMake files yourself, I can modify the CMake
> scripts so that the files are place in the right directories. To do this, I
> need a detailed directory/file structure of both the Hugin and the
> HuginStitchApp bundle.
Hugin.app/Contents/:
MacOS/:
hugin
Info.plist (specifies main executable "hugin", creator "Hgin", file
types, version info, icon files)
Pkginf (Hgin,APPL)
Resources/:
hugin.icns
huginfile.icns
HuginStitchProject.app/Contents:
Info.plist (specifies main executable "hugin_stitch_project",
creator "????", file types)
MacOS/:
hugin_stitch_project
Ippei
Yuval Levy
> Either way, I don't think it's plausible to limit architectures for
> testing would help in any way.
Limiting the choice of architectures does help reducing the effort (and
thus time) required until the next release is out.
Taken to the extreme, Pablo could have supported his Linux platform only
and left everybody else to their own devices. Most likely he'd be much
closer to a release than he is now.
I read reports of the same SVN version that does stitch on Intel OSX and
does not stitch on PPC OSX. This is the kind of situation that I wanted
you to think of. Breadth of support vs. time to release.
We can be perfectionist and insist on making it work on all platforms
before release, or pragmatist and make it work on a few selected
mainstream platforms. The difference is time to release, and at this
point a release is overdue.
> I think we should clearly separate the tasks of:
> - making hugin compile and run natively with simple CMake build
> supported by Fink/MacPorts, and
> - effort towards self-contained release package; CMake or Xcode,
> self-build libraries, cross-compilation, resources inside the bundle.
YES. But it still does not answer the platforms question. There is no
hugin for Windows on Alpha, and there is no hugin for Linux on PPC or
Motorola 68K AFAIK. Would it be tragic if at first (during the test
phase) there is no hugin for PPC OSX?
> They both have very different problems and wouldn't help us if anyone
> got them mixed up.
What they do have in common is that they take up time. The same way it
was decided earlier to postpone the latest wxWidget problems to after
release, the question I raise is whether it makes sense to spread the
resources on the legacy PPC platform and the current Intel platform or
if it is faster and more efficient to focus on getting the Intel version
out first?
> It would be a good idea to separate the threads as
> much as possible between those efforts. That way we can also prevent
> anyone joining the effort later (or someone like Yuv who wants to
> monitor our efforts nevertheless) from being confused by the two
> progresses we are making in parallel.
I am not confused. I understand the two different approaches and the
issues. And all I wanted to know with my question was how those working
on the OSX built felt about moving forward on many fronts at the same
time. You seem to be comfortable with it. My concern is that the OSX
build is far behind the Linux and Windows builds. I see an uncomfortable
situation coming, in which the Linux and Windows builds are ready for
release while the OSX is not. I hate it when Mac users are left behind,
but I also hate it when Linux and Windows users have to wait.
By putting up the critical question as to whether it is
necessary/desirable to support all OSX platforms I only want to make you
aware of the trade-off, and I hoped to see an answer / decision coming
from those of you who are making such a great effort to get it to work
on OSX.
I get hugin to build on my 32bit and 64bit AMD boxes. I have installed
the build chain and will try to get it to build on my Windows box as
well. If I had OSX running, I'd try to do it too. The current goal is to
get as fast as possible to a release candidate, and AFAIK we've agreed
that the release should be available for Linux/Windows/Mac.
AFAIK we have not discussed in detail what Mac means. We had discussed
in detail what Linux means, but the meaning has been extended thanks to
volunteers and because building hugin on Linux is so much easier than on
the other platforms.
yuv
Carl von Einem
Yuval Levy wrote:
> Ippei UKAI wrote:
>> Either way, I don't think it's plausible to limit architectures for
>> testing would help in any way.
>
> Limiting the choice of architectures does help reducing the effort (and
> thus time) required until the next release is out.
>
> Taken to the extreme, Pablo could have supported his Linux platform only
> and left everybody else to their own devices. Most likely he'd be much
> closer to a release than he is now.
>
> I read reports of the same SVN version that does stitch on Intel OSX and
> does not stitch on PPC OSX. This is the kind of situation that I wanted
> you to think of. Breadth of support vs. time to release.
Sorry but that sounds a little bit as if you'd like to cut out OS X
completely for the sake of early delivery of a cross platform software.
> We can be perfectionist and insist on making it work on all platforms
> before release, or pragmatist and make it work on a few selected
> mainstream platforms. The difference is time to release, and at this
> point a release is overdue.
Interestingly in the commercial world PPC is still a must, even if Intel
Macs have to run the software in compatibility mode. AFAIK even
Shockwave is not natively running on Intel Macs today.
>> I think we should clearly separate the tasks of:
>> - making hugin compile and run natively with simple CMake build
>> supported by Fink/MacPorts, and
>> - effort towards self-contained release package; CMake or Xcode,
>> self-build libraries, cross-compilation, resources inside the bundle.
>
> YES. But it still does not answer the platforms question. There is no
> hugin for Windows on Alpha, and there is no hugin for Linux on PPC or
> Motorola 68K AFAIK. Would it be tragic if at first (during the test
> phase) there is no hugin for PPC OSX?
Yes, for me. And maybe several others. (No question if we were talking
about still including Classic...)
OS X PPC is still widely in use and those machines are not necessarily
outdated yet. When I read of a release of enblend that supported > 4 GB
RAM (v1.3+RJP20050522) I decided to buy a new PowerMac G5. That was in
July 2005. No "Intel PowerMacs" available at that time, Mac Pro came in
August 2006.
So this machine is now 2.5 years old but it has:
- Dual 2.3 GHz PowerPC G5
- 6.5 GB DDR400 SDRAM (PC3200) - 2x 256 MB + 6x 1024 MB
(Max Total RAM would be 8192 MB)
- Serial ATA HDs
- came with Mac OS X 10.4 (Tiger)
- 1x FireWire-800, 2x FireWire-400, 3x USB 2.0
- 3x PCI-X
I think that's still a machine good for some stitching and blending.
BTW I still do most of my everyday work on a G4 PowerMac from 2001. That
machine still does everything I need for DTP, with only 867 MHz and 1.12
GB RAM. A little bit outdated for my stitching needs since I have a full
16 bit workflow based on scanned film. Terrible amounts of data.
Oh, and my 2004 PowerBook G4 (also PPC) with 2 GB RAM is mainly used to
control one of my three scanners.
All three Macs still can run the latest Mac OS X.
>> They both have very different problems and wouldn't help us if anyone
>> got them mixed up.
>
> What they do have in common is that they take up time. The same way it
> was decided earlier to postpone the latest wxWidget problems to after
> release, the question I raise is whether it makes sense to spread the
> resources on the legacy PPC platform and the current Intel platform or
> if it is faster and more efficient to focus on getting the Intel version
> out first?
Please also drop every support for Win XP, that is so legacy. Vista now
ships long enough! ;-)
Carl
Bruno Postle
>
> YES. But it still does not answer the platforms question. There is
> no hugin for Windows on Alpha, and there is no hugin for Linux on
> PPC or Motorola 68K AFAIK.
Actually current hugin trunk builds fine for Linux on ppc32 and
ppc64 (as well as i386 and x86_64, no idea about motorola):
http://koji.fedoraproject.org/koji/taskinfo?taskID=348425
--
Bruno
Yuval Levy
> Actually current hugin trunk builds fine for Linux on ppc32 and
> ppc64 (as well as i386 and x86_64, no idea about motorola):
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=348425
cool! Mac PPC owners, switch to Fedora!
:-)
Yuv
Yuval Levy
> Sorry but that sounds a little bit as if you'd like to cut out OS X
> completely for the sake of early delivery of a cross platform software.
If the words *you* are putting in my mouth were true, I would have have
stated such an opinion instead of wasting my time and that of others.
Next time, please read this list's past posts before expressing
offending, wrong and unfounded conclusions.
I have put more effort into motivating / prodding / pushing for OSX than
for windows, publicly, as well as off-list nagging of people I know have
access to relevant resources. I even asked for people at Apple itself to
help with the build (but Apple has a policy for its employees or its
hardware participation in open source projects).
I did all of this despite no personal interest nor access to OSX and you
accuse me of trying to kill the OSX hugin completely?
> Interestingly in the commercial world PPC is still a must, even if Intel
> Macs have to run the software in compatibility mode.
not having a Mac, I am not aware of this. That's why I would like to
witness a discussion of available resources, expected benefits, required
effort and alternatives amongst the Mac builders and testers. My
interest is to bring clarity to the trade-off between breadth (more
platform, more resources, slower progress) and depths (few platforms,
few resources, faster progress). The ultimate goal being that an OSX
release be ready in time.
The trade-off that plays between platforms (Win/Lin/Mac - and it has
been decided in the recent past to go with a release when there is
sufficient support for all three) also plays and within them
Win:2K/XP/Vista; Linux:ubuntu/fedora/suse/...; Mac:Intel/PPC/... and
that's where I sense that the Mac people are just going in one direction
without considering the implications. I am not saying it is the wrong
direction and I am not saying it is the right one. What I am saying is
that you guys should consider the required effort, the available
resources, the benefits and last but not least the available time and
alternatives, and make an informed decision.
In the end the result will be a compromise to which each and every
contributor will have contributed a bit, and since most contributors are
practically limited to the platforms they have access to, support and
development pace for those very same platforms is limited to the
available resources.
A release is long overdue and the window of opportunity is getting
smaller by the day. We need a cut-off time. Whatever is ready by then is
released, what is not is postponed for after release. It's a matter of
momentum and of timing. The users have been waiting for too long. The
world of panorama stitching has evolved a lot since the last hugin
release. The next GSoC is around the corner.
This is no commercial development.
If the users of a platform do not help themselves, or if they lack
resources to deal timely with the level of complexity associated with
their specific platform and sub-platforms, support for that platform
will be left behind. I don't want such situations to put a drag on
platforms that are thriving and moving fast forward; users of the
thriving platform will put pressure and help themselves to an
(unofficial) release, that will eventually replace the official release
if the official release is indefinitely delayed by the thin resources
affected to a platform that is so marginal to the project.
I am not saying which one is that platform - users, builders, testers
say that, by deciding how to spend the time and which platform to advance.
Users are screaming for a hugin release. There are so many improvements
in the current SVN since the last release that it could be easily
branded a 2.x release. But the constant state of flux hinders a wider
adoption of hugin and a move to the next level.
The Linux platform is close to a release. The Windows platform is
getting there. I have yet to see a report of a successful stitch on OSX
(and on PPC OSX even more) from somebody who is not a coder or a builder.
It worries me that when Linux and Windows will be ready, OSX won't be.
I'll rather have the discussion upfront, so that everybody is on the
same page. I don't care if you'll hate me for that. The chronic lack of
resources is part of OpenSource life.
I know Pablo does not want to commit to a deadline for a release, but I
think it is time to do so, and the right way of doing this is to start
releasing frequently regular incremental releases. This means commit to
a deadline but not to a set of features. What is not in for this release
will come for the next, and this include specific platform support.
Committing to a deadline for a specific set of features, I agree with
Pablo, is not feasible. But committing to a deadline for release, with
features being pushed further out in the future if they are not ready by
release deadline, that is feasible and should be done.
It is easier to start with a clean release of a working and tested
trunk. Then the developers need to ensure that they don't break too much
in the repository, at least not intentionally. The builders need to
ensure that weekly or even nightly builds are executed and pushed to the
testers so that when the next deadline comes it is easy to assess
whether a feature is ripe for release or not; whether a platform is ripe
for release or not.
I wish we could clean up the current status to a point where all
platforms build and work with a set of features, and that from there on
we can commit on a regular release schedule featuring those features
that have matured since the last release. Every three months would be my
dream. Every six months is excellent. Once a year would be good.
>> Would it be tragic if at first (during the test
>> phase) there is no hugin for PPC OSX?
>
> Yes, for me. And maybe several others. (No question if we were talking
> about still including Classic...)
OK, I understand that you have no access yet to an IntelMac, and that
your PPC Mac are too good yet to be replaced, and that there are
probably other people in the same situation. Would you consider donating
some of your time and your CPU power to build and test the hugin suite
as Bruno just mentioned, you have two alternatives - you could boot your
PPC in a true 64bit Fedora Linux environment and check it there, and you
can try with the OSX PPC version which so far, to my understanding, is
far from being functional. And you can make up your mind yourself.
> OS X PPC is still widely in use and those machines are not necessarily
> outdated yet.
oh, until two years ago I was still using a Quadra 700 (my last Mac) as
a mail server and test apache/php/mysql server. It ran perfectly in debian.
and my main file server, which I also use as a stitching engine, is a
ten years old Dell XPS-T with a pentium III CPU.
this is not about the machines being outdated or not. it is about the
platforms being main-stream and about the resources to support them. I
never even dreamed of demanding the Debian team continues to support the
68K architecture. I am surprised to see the pentium III still fully
supported by FreeBSD, Samba, Apache, PHP, MySQL, Subversion, Postfix and
the other packages that run 24/7 on my good old Dell.
This in a world where Apple's OSX runs only on Intel CPUs with SSE3
support (which excludes plenty of CPUs produced in the last few years,
some of them still valid 2GHz+ CPUs). Supporting SSE2 is not that
difficult, there are plenty of patches out there, from people who want
to run their Hackint0shes on slightly older hardware or on cool stuff
<http://uneasysilence.com/archive/2007/11/12654/>
> Please also drop every support for Win XP, that is so legacy. Vista now
> ships long enough! ;-)
Right :-) No Vista in sight anywhere near me. Pun intended. Seriously.
I'd personally drop Vista and XP for 2K, but the Win32 executable seems
to run on all three platform without the problems that other OS have.
In the end, the support is not for a system, but for people and from
people. If there are enough resources, any platform can and should be
supported. Unfortunately those resources are volunteers, and there is a
constant lack of skilled volunteers. I am not able to change a line of
code in hugin (yet).
Yuv
Ippei UKAI
On 2008-01-14, at 12:46, Carl von Einem wrote:
>
> Hi!
>
> Yuval Levy wrote:
>> Ippei UKAI wrote:
>>> Either way, I don't think it's plausible to limit architectures for
>>> testing would help in any way.
>>
>> Limiting the choice of architectures does help reducing the effort
>> (and
>> thus time) required until the next release is out.
>>
>> Taken to the extreme, Pablo could have supported his Linux
>> platform only
>> and left everybody else to their own devices. Most likely he'd be
>> much
>> closer to a release than he is now.
>>
>> I read reports of the same SVN version that does stitch on Intel
>> OSX and
>> does not stitch on PPC OSX. This is the kind of situation that I
>> wanted
>> you to think of. Breadth of support vs. time to release.
>
> Sorry but that sounds a little bit as if you'd like to cut out OS X
> completely for the sake of early delivery of a cross platform
> software.
Well, just for an early delivery, it's easiest to drop any 'support'.
It works for 'many' users. Or we could drop the self-contained build
because that would be the hardest bit.
>> We can be perfectionist and insist on making it work on all platforms
>> before release, or pragmatist and make it work on a few selected
>> mainstream platforms. The difference is time to release, and at this
>> point a release is overdue.
>
> Interestingly in the commercial world PPC is still a must, even if
> Intel
> Macs have to run the software in compatibility mode. AFAIK even
> Shockwave is not natively running on Intel Macs today.
Well, Shockwave is just being a legacy software.
It is true though that there are no applications around that have
dropped PPC support for an ease of development. Only exceptions I
know of are Parallels Desktop and VMware Fusion.
>>> I think we should clearly separate the tasks of:
>>> - making hugin compile and run natively with simple CMake build
>>> supported by Fink/MacPorts, and
>>> - effort towards self-contained release package; CMake or Xcode,
>>> self-build libraries, cross-compilation, resources inside the
>>> bundle.
>>
>> YES. But it still does not answer the platforms question. There is no
>> hugin for Windows on Alpha, and there is no hugin for Linux on PPC or
>> Motorola 68K AFAIK. Would it be tragic if at first (during the test
>> phase) there is no hugin for PPC OSX?
>
> Yes, for me. And maybe several others. (No question if we were talking
> about still including Classic...)
Right. My point was that for compiling with Fink/MacPorts, we
wouldn't get many architecture specific troubles. In past few years
I've worked with universal build, I've never encountered an
architecture-specific bug in hugin code. Anything I have dealt with
were something to do with cross-compiling, pano12, and OS versions. I
know of no code in hugin that uses CPU macro.
The difference between the two architectures is only the bit-order in
practice and nothing more programming-wise. The more prominent
problem usually lies in the different OS versions and other
configurations that users have on their machine.
I build hugin for 10.3.9 PPC and 10.4 i386. Since both are actually
cross-compiled, change of my main machine from old PB with G4 to new
Mac mini with Core2 Duo last year didn't affect anything. I believe
Harry inherited this set of minimum requirements for his self-
contained build. The difference between those versions make some
effect especially on wxWidgets implementations, and that has been a
problem.
The other possible correlating effect is the machine speed in
general. I have heard of a bug in Cocoa that some notification is
sent a little bit too early. This 'bug' only surfaces on a slow
machine regardless of the architecture, but, guess what, no intel
users could reproduce it. The general distribution of machine speed
strongly correlates with the shift in architecture.
Anyway, it is crucial overall that we distinguish the problems we
face in the two approaches. The debugging of the code itself would be
best done by any Mac users, on PPC or Intel alike, building hugin by
themselves with Fink/MacPorts. Meanwhile, getting something that
already works reasonably in the system-dependent builds self-
contained with and only with bugs that exist in the other approach is
the second task.
G5 and all Intel machines are all reasonably fast. My PowerBook is G4
867MHz bought in 2003, but I still carry it around everyday.
>>> They both have very different problems and wouldn't help us if
>>> anyone
>>> got them mixed up.
>>
>> What they do have in common is that they take up time. The same
>> way it
>> was decided earlier to postpone the latest wxWidget problems to after
>> release, the question I raise is whether it makes sense to spread the
>> resources on the legacy PPC platform and the current Intel
>> platform or
>> if it is faster and more efficient to focus on getting the Intel
>> version
>> out first?
>
> Please also drop every support for Win XP, that is so legacy. Vista
> now
> ships long enough! ;-)
In summary, I disagree. The development process would cut out half
the developer population of already a minority platform. It's just
not worth it given how small is the difference between systems
running on those architectures.
The current situation reminds me of the problems we had with
PToptimizer and autopano-sift. They had so much problem that we ended
up linking the PToptimizer code directly instead of calling the
command-line tool, and drop 'support' for autopano-sift. I wouldn't
expect an easy path on getting various tools we have now work
together well enough to the level that works on every machine.
For the side notes, we are still at the alpha stage of the
development. All the technologies (including the new exif code) just
have got glued together, and we are no where near the release in
terms of quality. I expect the Stitching tab to be renewed almost
entirely (the current one seems almost 1-to-1 with the parameters
inside pto file rather than any user orientated). Preferences need to
reflect the changes in the stitching architecture, as well as a list
of many other minor points (specifying output filename, passing the
project file to stitch_project via tmp dir rather than save and
stitch etc).
I'm not too worried about the development for Mac in particular yet.
The current focus on Mac should be to get the both build working.
Let's talk about debugging the distributed packages once we get the
stage it becomes critical. I'd rather take a look at the code than to
discuss about the development process with someone who's still trying
to understand the situation on the foreign platform.
Carl von Einem
Harry van der Wolf
Pablo dAngelo
> As Ippei states: I have already adopted Ippeis way of xcode producing universal binaries for ppc and i386 (no 64 bit yet, at least not from me) and also published a couple of them.
>
>
> With regard to the cmake way of compiling/building: There are two options:
> 1. "my system only" build
> I mailed a patch to the mailing list two days ago containing the addition for the cmake compilation of a "my system only" hugin for both macports and Fink for one architecture only, e.g. everyone on ppc or intel should be able to create now a working hugin.app for his/her system. I did not commit this patch to the SVN as I said three weeks earlier that I would not do that. But if it is not being picked up by Pablo I will do it myself (no offense meant Pablo if you are reading this).
> This patch needs to be tested by other users off course. Note: the mail was called: patch for cmake build MacOSX localisation
With respect to the "my system only" build, I agree with ippei that it should create a really bare bones hugin bundle (without localisation etc.). So the bundle would just contain the hugin exectuable (+ files required by OSX) and all other stuff (localisation, data files etc), should be handled exactly as on any other unix.
This also will mean that it will be much harder to break the build in the future, since it essentially uses the same process (and code) as on Linux.
Unfortunately, this requires some minor changes to the hugin code (currently all the code inside __WXMAC__ always expects a fully bundled hugin). If it looks like nobody can make the relevant changes, so probably I need to do it. Probably in a few days or so.
My comments:
The release is probably two weeks away (but don't nail me on this ;-)
> In short:
> - compiling a hugin.app for your own system via cmake and macports/fink is almost there (to be tested).
I agree, this is not far away.
> - compiling a one-architecture only portable bundle via cmake and Macports/fink is on its way => postponed for next release?.
> - compiling a cmake universal bundle will stay a manual labour =. outside releases.
From a typical end user perspective, either one of those is probably required to classify it as supported on OSX, with a preference for the universal bundle.
ciao
Pablo
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
Ippei UKAI
compile. Please correct. It also contains changes I made for myself,
so might want to revert some of the changes.
Ippei
On 2008-01-15, at 11:03, Pablo dAngelo wrote:
> Unfortunately, this requires some minor changes to the hugin code
> (currently all the code inside __WXMAC__ always expects a fully
> bundled hugin). If it looks like nobody can make the relevant
> changes, so probably I need to do it. Probably in a few days or so.
Pablo dAngelo
I'll take a look and fix the CMake stuff as well.. I have also just started to do this..
ciao
Pablo
______________________________________________________________________________
Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit
Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134