binary distribution policy

[Yuval Levy]

the following discussion was at [0] where it is off topic. It is
important here, hence the continuation:

--- In w...@yahoogroups.com, "Erik Krause" <erik.krause@...> wrote:
>
> On Saturday, November 07, 2009 at 22:37, yuval_levy wrote:
>
> > my opinion about that specific installer:
> >
> >
http://panospace.wordpress.com/2009/11/07/hugin-2009-2-0-windows-installer/
>
> I think hugin distribution politics is far from the high quality of
> the software.

Erik, If you think you can do better, go ahead and do it. You have all
the necessary information, tools, and accesses to distribute Hugin
differently.

Frankly I am annoyed. I know we have *different* views. I respect your
opinion. I do not accept your qualitative judgment. Have you done
anything better? Have you done anything at all other than criticizing?

There is no *politics* in the Hugin distribution. There are facts:

1. The development team does not have the resources to consistently
produce binaries for distribution. The nature and composition of the
team changes continuously. Slowing development because of binary
distribution is unacceptable to me.

2. Users have *always* built and distributed the binaries. It will stay
so as long as the necessary resources are not consistently available to
the project. Resources = combination of hardware, skill, time.

This is true for MacOSX; for Ubuntu; for Fedora; for Gentoo; for
FreeBSD; and for any other system on which Hugin is known to work. Why
should Windows be treated any different? Or why should the development
team deal differently with binary distributions? So far I have not seen
one single convincing argument from you or others that are so interested
in binaries but are afraid to dip a toe in the water.

3. It was a user effort that brought about the documentation for other
users to build binaries for all platforms [1]. And the 0.7.0 Windows
installer [2] was (my) user effort as well. Without users contributing,
*nothing* happens.

4. A member of the development team *may* also be a user of a specific
platform. He *might* produce binaries at some point, but this does not
imply commitment or obligation to produce, maintain, distribute, neither
in the present nor in the future; neither for him nor for the rest of
the development team.

5. *Nobody* can tell anybody what to do with their time. If you think
something is not being done as it should be; and you feel that your
critique goes unheard, you are free to
a) do it yourself
b) ask nicely once or twice
c) hire somebody to do it

and if nobody (including you) does it, then probably it is not important
enough (not even to you). If you are not ready to invest your resources
to do this, how can you expect that others do?

I have stated my *personal* opinion about the currently circulated
Windows installer at [3]. Note that it is my *personal* opinion on my
*personal* blog. I have not imposed my opinion on the project, nor on
Allard, nor on Windows users. His stuff is up there on Sourceforge as
official download despite my opinion, and we agree to disagree.

When I make changes to the project, I put forward a motion and it is
decided by consensus or by majority. My voice is one of many.

You can discuss your wishful thinking as long as you want. Criticizing
is easier than doing. Critique is welcome when it brings new findings to
the table. The repetition, again and again, of the same old stale wish
is annoying; and the judgment by those who have not even tried to do
something is worth exactly as much as they have done.

I personally see no reason to invest my resources in a Windows installer
at this time. I think it is something important to have, and it will
come in due time. Other things have higher priority for me at the
moment. If others think differently, they can invest their resources to
what they think is their highest priority.

The beauty of Open Source is that there is no boss. I don't need to find
here the same constraints that I find when I am paid to do something for
a customer or for a boss in a corporate environment. When I am hired for
money I'll bend over; be a prostitute; play the politics. If asked to do
something that I deem futile, I'll do it with a smile and won't even
utter my opinion. That's called "day-job".

I am here on my "free-time", which is the opposite of "day-job". Here I
enjoy the freedom of doing what I want, when I want, how I want.

Here I enjoy being a "social learner". Learning from more experienced
others and passing on to less experienced new comers.

In the "free-time" context, if my byproduct is helpful to others, good
for them. If it is not, they will have to find other ways to satisfy
their wants/needs.

In the "day-job" context is the other way around. If I like what I'm
doing, good for me. If not, I'll have to find other ways to happiness,
because customer satisfaction and following the boss' orders are what
counts there.

There, not here.

Yuv

[0] http://tech.groups.yahoo.com/group/wwp/message/11790
[1]
http://wiki.panotools.org/Development_of_Open_Source_tools#Supported_Platforms
[2]
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/installer/
[3]
http://panospace.wordpress.com/2009/11/07/hugin-2009-2-0-windows-installer/

[namklim]

On Nov 10, 4:46 am, Yuval Levy <goo...@levy.ch> wrote:
> the following discussion was at [0] where it is off topic. It is
> important here, hence the continuation:
>
> --- In w...@yahoogroups.com, "Erik Krause" <erik.krause@...> wrote:
>  >
>  > On Saturday, November 07, 2009 at 22:37, yuval_levy wrote:
>  >
>  > > my opinion about that specific installer:
>  > >

>  > >http://panospace.wordpress.com/2009/11/07/hugin-2009-2-0-windows-inst...

>  >
>  > I think hugin distribution politics is far from the high quality of
>  > the software.
>
> Erik, If you think you can do better, go ahead and do it. You have all
> the necessary information, tools, and accesses to distribute Hugin
> differently.
>
>

From a Windows user viewpoint I agree with Erik; the Win binary
distribution is a mess.

If you look at the number of downloads for v 0.7 then the Win
downloads (224,774) are many more than the Mac (73,199) downloads. I
don't think you can expect all those Win users to compile Hugin
themselves. Very few would have the skills to do so. Win users just
expect to have to download, then to run an installer and then to get
on with using the software.

And as you've pointed out on Panospace there is confusion about what
is being included in releases. There is a need for strict control. I
think they may be several different versions of 0.8 available for
download from different sources which may or may not be the same. It
will eventually become a nightmare if users start asking why something
doesn't work and another says it does for the same apparent version.

I'm not sure the change to more versions (2009-x) appearing more
quickly is helping. A version every three or six months would seem to
be more reasonable if the resources are not available to complete the
whole release process in a systematic manner more frequently.

To me, GIMP seems much more professional in distribution of binaries.

[Yuval Levy]

namklim wrote:
> From a Windows user viewpoint I agree with Erik; the Win binary
> distribution is a mess.

I don't disagree with the qualification of the Win binary distribution.
I disagree with the judgment of what the developers team does.

> If you look at the number of downloads for v 0.7 then the Win
> downloads (224,774) are many more than the Mac (73,199) downloads. I
> don't think you can expect all those Win users to compile Hugin
> themselves. Very few would have the skills to do so. Win users just
> expect to have to download, then to run an installer and then to get
> on with using the software.

Agree that very few would have the skill to compile an installer. If
there is one in 73,199 that's just enough. Mac users have Harry (and a
few more that help him along). Statistically, shouldn't there be about
three in 224,774 that can do that?

Why do Win users like Erik (and apparently yourself) criticize the
developers? they should criticize those three Win power users amongst
themselves. If you look at the archives of this list, you will find more
than three Win users who in the past twelve months have obviously built
Hugin, often with answers/help from the developers. Ask them why they
don't release the result of their work in the way that you'd like it.

Why should Win users be different than Mac users? or Linux users? *all*
users just *wish* (*expecting* is arrogant in an Open Source context) to
download/install a binary and get on with using the software. The
difference is that 0.001% of Mac users raise up to the task. That's
enough to give all Mac users what they wish for. Ask Windows users why
nobody of them raise up to the task?

> And as you've pointed out on Panospace there is confusion about what
> is being included in releases. There is a need for strict control.

Control and Free software don't go well together.

Ultimate responsibility is with the user: know what you download and
from whom.

> will eventually become a nightmare if users start asking why something
> doesn't work and another says it does for the same apparent version.

From a developer perspective, Windows users are a nightmare anyway.
Most bug reports are incomplete. Since we no longer accept anonymous
ones, we get at least the chance to help them complete the bug reports.

In the end, most problems are on the user side, and very seldom a
problem of the installed binary.

> To me, GIMP seems much more professional in distribution of binaries.

<sarcasm>then what are you doing here? go there and use GIMP. Or ask the
GIMP team to release Hugin for you.</sarcasm>

Seriously - from [0]

"This site, www.gimp.org, only distributes the GIMP source code (the
building blocks). You can however download executable versions from the
following site:"

which points to [1] - a different project.

If you want to start [2], you have my blessing.

Yuv

[0] http://www.gimp.org/windows/
[1] http://gimp-win.sourceforge.net/
[2] http://hugin-win.sourceforge.net/

[Erik Krause]

Yuval Levy wrote:

> Erik, If you think you can do better, go ahead and do it. You have all
> the necessary information, tools, and accesses to distribute Hugin
> differently.
>
> Frankly I am annoyed. I know we have *different* views. I respect your
> opinion. I do not accept your qualitative judgment. Have you done
> anything better?

No. Why should I? Did you do anything better? You had only critics for
the recent windows distribution:
http://panospace.wordpress.com/2009/11/07/hugin-2009-2-0-windows-installer/
In my opinion this does far more harm to the hugin project than my
criticism (which only states a fact BTW). What you write in your blog
should be discussed internally and not mentioned in a public place where
someone asks for a stitcher recommendation.

How comes, that you criticize me for pointing out an insufficiency?
Reporting bugs should be honored not flamed like you do on me.

> Have you done anything at all other than criticizing?

No critics allowed? Fear of facts? Hugin is superb. The fact that I had
to wait for a year for a recent hugin distribution is annoying. And your
behavior against anyone who dares to say anything about hugin
distribution is more than annoying, it discredits the whole project.

[...]

For the rest of your sermon: Read again what I wrote: I didn't demand
anything, I didn't tell anyone what to do or what not. I even don't want
hugin for me. I support the hugin project with part of my time since I
think it's a good thing to support free software. But you don't make it
easy for me (and for others) to keep up this sympathy. And I fear others
aren't as patient as me.

Now look at what you did in your blog: You demanded something, you asked
for others time. Why do you measure yourself by different goals?

In other words and if you still didn't get it: I think you distract
people from using or even trying hugin.

And BTW.: I won't read any longish reply to that. If it is as short as
"I'm sorry", I will...

best regards
--
Erik Krause
http://www.erik-krause.de

[Yuval Levy]

Erik Krause wrote:
> In other words and if you still didn't get it: I think you distract
> people from using or even trying hugin.

maybe he's right?

good bye everybody, have fun with your new leader Erik.

Yuv

[allard]

C'mon guys. Spend your energy on solving bugs or something.

[anbue]

Thanks again, Allard.

[Ryan]

Hi all,

On Nov 11, 10:32 am, anbue <andreasbuett...@anbue.de> wrote:
> Thanks again, Allard.
++

<short-version>
- It's a royal pain in the neck to build hugin for Windows (far worse
than for Linux, it seems)
- It might be worth "subsidizing" a bit more the non-techie artists
out there who use Windows... we're talking about creating art here,
not bootstrapping gcc or compiling the linux kernel. Like it or not,
they need a tool, not a compilation project.
- Can we sidestep patent issues by putting a click-though agreement
between users and the CP generator, like people do for export
restrictions?
</short-version>

Long version follows...

For the record (as one who has spent 100+ hours trying to build
hugin), I didn't release an installer for very simple reasons:
1. I have no clue how, and no access to MSVC ;). I did put up a .zip
of my cygming build, though (thanks to yuv and rick for all the help).
2. I don't have access to a decent graphics card to debug the GPU
problems Rick found in nona
3. "Imperfect" or not, allard's 2009.2 installer beats the pants off
the 0.7 version I was using before, and also beats my cygming build
even ignoring GPU issues. If a static cygming build of enblend-4.0
would help him out I'm all ears.
4. Compiling hugin sounded like a good idea about 100 hours of labor
ago, but at this point I've spent far longer trying to build hugin
than went into every panorama I've ever stitched -- combined.

I know somebody said that it's a show-stopper if the MSVC build
breaks, but the dearth of installers, the embarrassing win32 wiki
page, and my (limited) experience suggests that windows is not a first-
class platform. It should at least be possible to at least generate a
working executable out of the box. Granted, though, many of the
problems I ran into are actually with hugin's dependencies...

As for the importance of having a windows installer, the people who
benefit most from hugin are the *artists* and *photographers* out
there, and they don't necessarily have -- let alone know how to use --
a compiler. My brother, the photographer/cartoonist/law-student who
loves hugin, would be helpless without folks like Allard. And, no,
he's not likely to switch to linux before the heat death of the
universe.

Re patent issues: the separate CP download is definitely good (I'd
favor a stand-alone installer rather than "with" and "without"
versions of hugin). We might further avoid liability by forcing the
user to click a button saying "those patent restrictions don't apply
to me" before downloading. Kind of like the export restrictions for
encryption. IANAL, but IMO the hugin project does not make any
commercial use of the encumbered software (no sales, no support,
nothin'); the sift algorithm, at least says explicitly that non-
commercial use is OK every time it runs; and a click-through agreement
would make clear that we don't encourage infringement by others.

Finally, as far as cygming goes, the reason I favored it is:
1. It follows the development cycle most hugin developers seem to use
2. Anybody can install cygwin, for free. I hear it's even possible to
set up a mingw32 cross-compiler on linux
3. The "One Makefile to rule them all" I developed is a first step
toward automated building/testing/packaging

Unfortunately, I don't have time or means to carry it any further...
hugin's a great tool, though, so I hope somebody can.

$0.02
Ryan

[Bart van Andel]

On 11 nov, 13:05, Ryan <scov...@gmail.com> wrote:
> 2. Anybody can install cygwin, for free. I hear it's even possible to
> set up a mingw32 cross-compiler on linux

I'm actually trying to get this working. Currently I have an Ubuntu
9.04 installation inside VirtualBox (on Windows host), and I'm using
mingw-cross-env [0, 1] as a cross build chain. One of the policies of
mingw-cross-env is to create static libs when possible, thereby
avoiding DLL hell (quote: "creates libraries to be linked statically,
no DLL hell"). Just like the point of view of some builders on the
Hugin block.

Before being able to compile Hugin, first the dependencies have to be
cross-compiled. The setup of mingw-cross-env makes this pretty easy: a
small script called <name-of-library>.mk has to be created with some
variables pointing to download location and build instructions (with
proper arguments to create cross-compiled executables).

So far I've successfully contributed libplot to the cross-build chain.
When all necessary dependencies are built, I'll see into building
Hugin itself. If anybody else wants to contribute by helping build the
dependencies, for example, please do! More detailed instructions can
be found at [0]. Volker (the mingw-cross-env general hero) can be
contacted using the project mailing list at [2], or by email (see
bottom of [2] for the address).

If this approach is successfull, it will become easier to keep the
Windows builds in line with the Linux (and OSX) build, since in theory
they can be built on the same machine as the Linux build. I hope the
speed of the cross-build will be comparable to the MSVC build...

> 3. The "One Makefile to rule them all" I developed is a first step
> toward automated building/testing/packaging

I'll keep that one in mind for the cross-build (if I need it)!

> Unfortunately, I don't have time or means to carry it any further...
> hugin's a great tool, though, so I hope somebody can.

It sure is. I'm spending more time on Hugin than I should, really, but
it's worth it!

[0] http://www.nongnu.org/mingw-cross-env/
[1] http://hg.savannah.gnu.org/hgweb/mingw-cross-env/
[2] http://lists.nongnu.org/mailman/listinfo/mingw-cross-env-list

--
Bart

[Ryan]

On Nov 11, 1:49 pm, Bart van Andel <bavanan...@gmail.com> wrote:
> Before being able to compile Hugin, first the dependencies have to be
> cross-compiled. The setup of mingw-cross-env makes this pretty easy: a
> small script called <name-of-library>.mk has to be created with some
> variables pointing to download location and build instructions (with
> proper arguments to create cross-compiled executables).
>
> So far I've successfully contributed libplot to the cross-build chain.
> When all necessary dependencies are built, I'll see into building
> Hugin itself. If anybody else wants to contribute by helping build the
> dependencies, for example, please do! More detailed instructions can
> be found at [0]. Volker (the mingw-cross-env general hero) can be
> contacted using the project mailing list at [2], or by email (see
> bottom of [2] for the address).

You might take a peek at the build files I uploaded [0], because they
include the patches and configuration options used to compile hugin
and its assorted dependencies (what is libplot, btw?).

As for comparing the compilations, I didn't notice any particular
speed difference, but I think the debug and exception handling extras
which gcc outputs are significantly more verbose than MSVC, with the
result that binaries are bigger. Either that, or the MS installer is
really good at compressing...

[0] http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cygming-build.tar.gz

Regards,
Ryan

[Stefan Peter]

Bart van Andel schrieb:

> On 11 nov, 13:05, Ryan <scov...@gmail.com> wrote:
>> 2. Anybody can install cygwin, for free. I hear it's even possible to
>> set up a mingw32 cross-compiler on linux
>
> I'm actually trying to get this working.

...

> If anybody else wants to contribute by helping build the
> dependencies, for example, please do!

I would like to participate here. Is there a homepage or a repository
where your current work is accessible?

With kind regards

Stefan Peter

[Bart van Andel]

> You might take a peek at the build files I uploaded [0], because they
> include the patches and configuration options used to compile hugin
> and its assorted dependencies (what is libplot, btw?).

I will. As far as I can see, most patches are for libraries which are
already part of mingw-cross-env (see [1]), so I'm not sure if I'll
really need them. And it's plotutils (not libplot, whoops), which
provides libxmi, one of the dependencies.

> As for comparing the compilations, I didn't notice any particular
> speed difference, but I think the debug and exception handling extras
> which gcc outputs are significantly more verbose than MSVC, with the
> result that binaries are bigger. Either that, or the MS installer is
> really good at compressing...

Ok, I'll just see.


> [0]http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cyg...

[1] http://www.nongnu.org/mingw-cross-env/#packages

--
Bart

[Bart van Andel]

> > If anybody else wants to contribute by helping build the
> > dependencies, for example, please do!
>
> I would like to participate here. Is there a homepage or a repository
> where your current work is accessible?

Easiest thing to do: pull directly out of mingw-cross-env repository
(assuming you want install it in /opt/mingw-cross-env):
$ cd /opt
$ hg clone http://hg.savannah.nongnu.org/hgweb/mingw-cross-env mingw-
cross-env

So far I've only contributed plotutils (including libxmi), and this is
in the repository now, so you'll have my copy as well.

If you don't have mercurial, you can install it using "sudo apt-get
install mercurial" (or with another package manager).


To get you started:
- First, compile the cross build package. You won't need all of it, so
just do the following:
$ cd /opt/mingw-cross-env
$ make gcc
- For any other required package, you can either execute "make
<package>" or just get the dependencies right (see below). In fact if
you include gcc as a dependency (you should), this will be built
automatically as well.
- Choose a dependency to work on (I assume "lcms" for this example).
- Create a copy of one of the .mk files in the mingw-cross-env/src
directory (lcms is hosted on sourceforge, so pick one of the other
sourceforge-hosted packages):
$ cd /opt/mingw-cross-env
$ cp src/glew.mk src/lcms.mk
- Edit the newly created .mk file. Look at the other .mk files to see
how things are done.


Every .mk file basically has three sections:
- At the top, some variables are defined which define the package
name, general download url, dependencies, and version information. The
checksum will be autogenerated so don't bother editing it.
- Function to retrieve the latest version from the web.
- Function to actually build the package.


I suggest first getting the retrieve function to work. Although this
obviously isn't the most crucual part, it helps understanding the
mingw-cross-env. This cross-building setup is really neatly setup, so
if you get this part working correctly, for new versions, nothing
serious has to be edited to the .mk file.

To test if the retrieve function works correctly (and download the
package automatically if it does), you can do the following:
$ cd /opt/mingw-cross-env
$ make update-checksum-lcms

This automatically checks for the newest version, and if it is found,
it will be downloaded, and the checksum will be added to the .mk file.
This is basically what I did.


The next step will be the actual compiling. Again, check out other .mk
files for a general idea on how this works. Then, you'll have to find
out which options to apply for your chosen dependency package. If
you're lucky, not a lot of changes are needed (ideally none to the
source files). If you're not, you might need to create some patches.
'Make'ing your package (in this case, lcms) works like this:
$ cd /opt/mingw-cross-env
$ make lcms

Note that everytime you call this "make lcms", the downloaded source
archive will be extracted after deleting any previously compiled
content. So don't forget to save any patches to a different folder (I
just copied my files to my home folder). The .mk files will only be
auto-filled with version information, no other changes will be a
applied, so you're safe here. But just to make sure, make backups of
your files here as well.

During building, a log file will be created in the mingw-cross-env/usr
directory, named log-<package>, e.g. log-lcms. You can examine out
this file to get it working. For some packages there is information
available on cross-building, just search for "cross building lcms" for
example.


This should get you started. If you have any questions, you can of
course post them here (note that I just started using this cross-build
chain last week), or on the mingw-cross-env mailing list I mentioned
earlier, or by contacting Volker.

Good luck!

--
Bart

[T. Modes]

> - It's a royal pain in the neck to build hugin for Windows (far worse
> than for Linux, it seems)

What's so complicated?
The most necessary libraries can be downloaded in pre-compiled form in
the SDK (http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK).
What's missing for current hugin version is glut. A precompiled glut
library for hugin can found here (http://groups.google.com/group/hugin-
ptx/msg/5bfc12ee00c5ac3c)
Download both packages and unzip a new folder. Then follow the
instruction on the wiki (skip the step of compiling enblend, for
enblend there are more libraries necessary. For a first try you can
use the precompiled version from sourceforge):
Run CMake -> open hugin.sln -> compile -> install (-> maybe build
installer)
I find that's very easy.

>1. It follows the development cycle most hugin developers seem to use

The cmake build works fine on windows. It's also up to date.

>2. Anybody can install cygwin, for free. I hear it's even possible to
>set up a mingw32 cross-compiler on linux

Anybody can also install the Visual C++ Express Edition, this works.
(see wiki instructions).

>3. The "One Makefile to rule them all" I developed is a first step
> toward automated building/testing/packaging

There are also some version of the automated cmake-build and installer
creation on the list (e.g. http://groups.google.com/group/hugin-ptx/msg/b3aff5888a9a2b87).
Why invent the wheel twice? It would be better to bundle the force for
one working version and not to split into several different ways to
get the similar results.

Thomas

[Bart van Andel]

> - Choose a dependency to work on (I assume "lcms" for this example).

Note: I've just built lcms myself, so no need to work this one out
anymore. I've just emailed it to Volker, so I expect it will be added
to mingw-cross-env soon.

[Bart van Andel]

Built glut (actually, freeglut) as well, just now. Mail is underway to
Volker. So far he's been rather quick in replying, so I suspect it
won't take long before both lcms and freeglut will be integrated.

--
Bart

[Bart van Andel]

> Easiest thing to do: pull directly out of mingw-cross-env repository
> (assuming you want install it in /opt/mingw-cross-env):
> $ cd /opt
> $ hg clone http://hg.savannah.nongnu.org/hgweb/mingw-cross-envmingw-
> cross-env

Forgot to mention: there are some dependencies... More on this here:
http://www.nongnu.org/mingw-cross-env/#requirements

--
Bart

[Jeffrey Martin]

> Why should Windows be treated any different?

ROTFL

because 90% of the people (and from them, people who might also become
DEVELOPERS of hugin) are there.

can it really get any simpler than that?

:-)

[Jeffrey Martin]

This reminds me of the scene in Fawlty Towers, when Basil is trying to
have a "fire drill".

The burglar alarm goes off by mistake. And people think it's the fire
drill which starts in a few minutes. They spend so much time arguing
about it, that the fire drill is late. Meanwhile, Manuel accidentally
starts a fire, but Basil doesn't believe him, and locks him in a
burning room.




All the time spent arguing about how lazy and useless people are (i'm
not naming any names here), the windows version could have been
compiled. Numerous times.



Jeffrey

http://www.youtube.com/watch?v=kn15BUFBvu8

[michael crane]

I agree, I think focus should be on making a solid software rather
than trying to change the world.
regards
mick

[Stefan Peter]

Jeffrey Martin wrote:
> All the time spent arguing about how lazy and useless people are (i'm
> not naming any names here), the windows version could have been
> compiled. Numerous times.

Ok then, please stop arguing and start your compiler ..

Regards

Stefan Peter

[Stefan Peter]

Jeffrey Martin schrieb:

As I have mentioned in another thread, hugin is not about market share
or world domination. Hugin allows a unix user to create panoramas using
a GUI. It was an itch to scratch, and the scratching required
significant efforts from all participants.

As the 90% windows users do not seem to scratch, they do not feel the
itch. So why should others do the scratching for them? Without having a
motivation other than getting rid of messages like the one that started
this thread? And having to support an operating system most of us do not
use or even despise?

There is an ongoing discussion in the free software community regarding
the wisdom of porting free software to windows. Some take the position
that it hinders the goals of free software, others think it helps to
spread the word. However, it is very clear for all of us that they can
not claim a right to be served with binaries, installers and support.

Of course, if windows users stand up and start to tackle this problem,
they will find help on this list.

Regards

Stefan Peter

[Harry van der Wolf]

2009/11/15 Stefan Peter <s_p...@swissonline.ch>

There is an ongoing discussion in the free software community regarding
the wisdom of porting free software to windows. Some take the position
that it hinders the goals of free software, others think it helps to
spread the word. However, it is very clear for all of us that they can
not claim a right to be served with binaries, installers and support.

That's right! We have seen a lot of criticism from windows users about not having a binary distribution (And I don't want to offend the "good" users who have already contributed (a lot) one way or another. I name them now users but they were already contributors, even though all of them are not builders).

This is Open Source. You have the RIGHT to build it yourself. Then BUILD it YOURSELF if you want to have it! You can't have it all and do nothing. It's Open Source which is not the same as "get everything for nothing".
If you don't want to build than stop whining and pay for commercial software.
If you want to use this great piece of software than learn and contribute.
 

Of course, if windows users stand up and start to tackle this problem,
they will find help on this list.

I couldn't have said it better!
Read the "Build hugin for Windows with SDK" and start for yourself. The wiki is regularly updated.

 

Regards

Stefan Peter

Harry 

[Erik Krause]

Stefan Peter wrote:

> As the 90% windows users do not seem to scratch, they do not feel the
> itch. So why should others do the scratching for them?

That's not the point. The point is that after a long time someone
finally created a binary for windows and the self-appointed leader of
this list has nothing better to do than distracting people by stating
that he "doesn't endorse this installer" - in a place where someone
asked for recommended stitching software. This is bad politics.

> Of course, if windows users stand up and start to tackle this
> problem, they will find help on this list.

Apparently not. It would have been wise to encourage allard by thanking
him for the windows installer. To "not endorse" his installer it looks
as if creating a windows installer is officially discouraged.

[Stefan Peter]

Erik Krause wrote:
>> As the 90% windows users do not seem to scratch, they do not feel the
>> itch. So why should others do the scratching for them?
>
> That's not the point. The point is that after a long time someone
> finally created a binary for windows and the self-appointed leader of
> this list has nothing better to do than distracting people by stating
> that he "doesn't endorse this installer" - in a place where someone
> asked for recommended stitching software. This is bad politics.

Free software development means that you are free to have an opinion and
state it. It means that you don't have to agree on everything and can't
be forced to do or approve something if you don't want to.
Your critic would have been justified if Yuv had prohibited the
publication of the installer.
And please stop this "self appointed leader" thing. Yuv has taken the
lead in a very important issue with the blessing of all participants.
Otherwise, there would have been a lively discussion about it on this
list. He lately has invested a tremendous amount of time and work in
order to reorganice the source releases and allow us to entangle the
different development projects. And he was responsible for the 0.7
binary release for windows. Therefore, he certainly has a voice in these
issues.

>
>> Of course, if windows users stand up and start to tackle this
>> problem, they will find help on this list.
>
> Apparently not. It would have been wise to encourage allard by thanking
> him for the windows installer. To "not endorse" his installer it looks
> as if creating a windows installer is officially discouraged.

You will have to face it: Yuv has worded at least one point, the
distribution of a copyright encumbered binary, that in every free
software project would have raised discussions. And in this issue, I
agree with Yuv: we will have to find a solution for this. And from my
point of view, this should have been solved prior to the official release.

As I do not own a windows system privately, I can not judge the quality
of the latest official windows binary installer. But I know from lurking
on this list that Allard has done a really good job despite lacking
support in the testing stage from most of these 90% windows users.
However, if his only motivation had been praise, there would have been
less elaborate ways. BTW, here would be an opportunity for you to catch
to flies with one blow: Use his release and let the list know about
problems and successes. This way, he knows that his work is appreciated.


Regards

Stefan Peter

[Harry van der Wolf]

At the moment I wanted to press "send" in reaction of Erik's mail, Stefan's mail came in. His mail describes exactly what I also wanted to say (and I dare say his mail was better than mine). It means that my mail can be much shorter. I still write it to show that other people agree with Stefan's words.

2009/11/15 Stefan Peter <s_p...@swissonline.ch>

Erik Krause wrote:
>> As the 90% windows users do not seem to scratch, they do not feel the
>> itch. So why should others do the scratching for them?
>
> That's not the point. The point is that after a long time someone
> finally created a binary for windows and the self-appointed leader of
> this list has nothing better to do than distracting people by stating
> that he "doesn't endorse this installer" - in a place where someone
> asked for recommended stitching software. This is bad politics.
>

Referring to the same point about the "self-appointed leader".
Yuval never claimed to be the leader, he always talks about the community as a whole. Yes, Yuval took leadership and he took initiative and he supported that with a huge load of work he took upon him! By doing all this (see Stefan's comments) he lifted Hugin again to a higher level (and let's not forget Bruno Postle who helped Yuval during the start of this restructuring). This is what I call a true leader, not a self-appointed leader. Others did nothing in this direction (including myself) and we were happy to follow.  He brought structure and clarity to the release process. He was the one who tried to structure and merge the GSOC 2009 projects with the ongoing developments. He wrote and modified documents to explain it to the community and help this community so that in the case "the leader" would disappear the community could survive. I'm very grateful for all his work and achievements.
He coordinated all the GSOC 2009 project stuff around Hugin. He was release manager for the 2009.2 release, he was release manager in the 2009.4 release until this happened. He has contributed hugely to Hugin (and other Open source projects as well) and all in his free time. (And I know that you are a contributor as well adding your droplets to the hugin package and improving them over time).
Two weeks ago (or so) Yuval asked in this list for release managers for the next release where he offered his assistance, because he wanted to take a step back. In what organization does a "self-appointed leader" ask other persons to take over?
Until some hours ago I really was in doubt about this mail thread but I'm not anymore.

Yuval has contributed a lot to Hugin over the years and really made the evolution of Hugin a bit of a revolution in 2009 due to his contributions.

I only agree with you that Yuval's criticism was a bit harsh towards Allan as Allan only tried to bring a new windows binary to the community. Allan needs our support to make it better (if he still wants to continue after the criticism for what he did for the community).
On the other hand: I also support Yuval in this as Yuval always strives for the highest quality (that's why he started this new release strategy and setup). Having such a "quality manager" in the team is very good.

I asked for Hugin OSX builders in my recent "Hugin OSX publication" mails. Three of them reacted on that and are now learning to build a bundle where one of them is ready IMO to release his own bundle now.
We should do the same for Windows. If Windows holds 90% percent of the users we should at least be able to get 10 builders.

regards,
Harry

[Erik Krause]

Stefan Peter wrote:

> Free software development means that you are free to have an opinion
> and state it. It means that you don't have to agree on everything and
> can't be forced to do or approve something if you don't want to. Your
> critic would have been justified if Yuv had prohibited the
> publication of the installer.

Sorry, it was not me who brought this discussion here. And it was Yuv
who was "annoyed" and accused me of demanding things, which is totally
nonsense in this case. I didn't demand anything, I expressed my
disappointment with the politics regarding windows binaries.

There was no point to bring the "If you want to have binaries, compile
them yourself" sermon again. And this "Contribute something before
criticizing" sermon is plainly silly and ignorant.

Why do you guys make it so hard for someone to simply test or recommend
hugin? Why this raised forefinger and this teacher's attitude all the
time about what open source software is and what not? Don't you see that
this sounds arrogant? Even worse: It might sound as if hugin developers
don't want and don't like their users.

You complain that there where no windows testers. There are lot's of
people willing and wanting to test hugin and to supply bug reports - me
included (perhaps you noticed: I supplied one shortly after the binaries
where available).

But most windows users (me included) won't go through the hardships of
compiling hugin to supply a bug report. And if I supply bug reports I
want to do it for a software "as is", not for something where I don't
know whether I introduced the bugs myself...

[Harry van der Wolf]

Hi Erik,

2009/11/15 Erik Krause <erik....@gmx.de>

Sorry, it was not me who brought this discussion here. And it was Yuv
who was "annoyed" and accused me of demanding things, which is totally
nonsense in this case. I didn't demand anything, I expressed my
disappointment with the politics regarding windows binaries.

It's not about the discussion itself or how it got here. That is completely valid here and your criticism as such is also valid. It's more the "choice of your words" that made me react ("self appointed leader" and so on), which is unfair and doesn't give Yuv the credits he deserves.
 

There was no point to bring the "If you want to have binaries, compile
them yourself" sermon again.

I mentioned that too and it's also the risk of such a mailing list that can easily end up in a flame war (but you know that as a moderator for another list). My point is that I've heard a lot of complaints and only one remark "I'm looking into it and trying to master the build" (free form quote). If nobody acts, nothing will happen. My motivation is that if it doesn't come to you, get it yourself.  Ippei did a great job in making Hugin up-to-date for OSX. His contributions have made Hugin on OSX a great piece of software. He didn't complain and wait but took initiative to get that going. He is less active lately, but when necessary he kicks in when a non-developer like me can't solve some OSX specific issues. One thing I didn't like was that Ippei only occasionally released svn builds (from the same argument: If you want it then learn how to build it). That's why I started building Hugin for OSX: to get more up-to-date builds.
I'm not a developer. I can't add new functionality. I can build, but I had to learn that as well. Same for new windows builders.
 

And this "Contribute something before
criticizing" sermon is plainly silly and ignorant.
 

I agree with you. Next to that I know that you did contribute a lot over the years, for Hugin windows users most directly via your droplets, but not only to Hugin. You also deserve credits for that.

 

Why do you guys make it so hard for someone to simply test or recommend
hugin? Why this raised forefinger and this teacher's attitude all the
time about what open source software is and what not? Don't you see that
this sounds arrogant? Even worse: It might sound as if hugin developers
don't want and don't like their users.

This statement is not correct.
First of all: the hugin project consists of a lot of testing and a lot of bugs are reported in this community. Nobody gets flamed for reporting bugs or for testing. Again: it's how it is stated. Rick (Rueike) is a consistent windows tester and therefore also bug reporter but he doesn't get flamed. He's appreciated for doing this testing.

W.r.t. "not liking their users":
It's off course nonsense to say that the "contributors" only do it for the community and to serve the world, but most of them are really service minded: Solving bugs on platforms that they do not even use, building functionality that is requested but which might not be usefull to themselves, building bundles/packages/rpms which take extra time from them but is not beneficial for themselves.
It is logical that "developers" do react, like I do now, when they put free time in a project like this that would have resulted in quite some money if the hours were spent on consultancy basis. We are not in for the money and neither to be honoured. But it's not fair to accuse Yuv from stopping the progress of Hugin where he contributed so much (and yes: I know that he's black-and-white in his sometimes very sharp arguments. I do not always agree or approve either).
Just the fact that I react now, even though windows is the very least of my concerns, comes from involvement with this project. And that's valid for most contributors.

 

But most windows users (me included) won't go through the hardships of
compiling hugin to supply a bug report. And if I supply bug reports I
want to do it for a software "as is", not for something where I don't
know whether I introduced the bugs myself...

I fully understand that "most windows users won't go through the hardships of compiling hugin.." as that's the same on all platforms, also for me. I build Hugin, Avidemux, ImageFuser, KImageFuser and Panini, but almost all of my software comes from simply downloading it as an end user (like VLC, Firefox, Burn, Gimp, Handbrake, OpenOffice, Chicken of the VNC and many more).
So far, the biggest platform, which windows is without question, delivered only very few builders (thank you guys) where it should have delivered the biggest amount of builders.
Just the simple fact that nobody takes the initiative to come forward as volunteer is disappointing.
Again: thanks to those who already did a great job in building windows binaries. It's just that there are obviously not enough builders.

regards,
Harry

[Harry van der Wolf]

2009/11/15 Harry van der Wolf <hvd...@gmail.com>

Just the simple fact that nobody takes the initiative to come forward as volunteer is disappointing.
Again: thanks to those who already did a great job in building windows binaries. It's just that there are obviously not enough builders.

regards,
Harry

I have to apologize here: In a parallel thread on this mailing list that has been dormant for a while, two windows volunteers are trying to build Hugin for windows. Great! (And guess who is helping them)
Still, on such a big community more builders are expected to step forward.

Harry

[allard]

Okay, before people start speculating about how I feel about Yuv's
comments on my installer or grossly misspelling my name (en dat van
een landgenoot, Harry!) maybe I should step in.

-Firstly, I want to make clear that I have had a lot of help from Yuv,
both in learning to first build hugin and in creating the installer,
even after it was clear that my sight was set a bit lower than his
when it comes to overall quality of the package. His comments did not
come as a surprise to me and have not discouraged me in any way. In
fact I agree with many of his criticisms on the installer. I disagree
only on whether those points justified not releasing the installer and
keeping Windows users on the lame 0.7 version.
-Secondly, I once was one of those Windows users that just downloaded
the binary and never contributed anything. In fact, to most of the
other OSS projects I use, I still am. It can take time for an itch to
develop. I never would have been part of the project if there had been
no windows binaries for the 0.6 and 0.7 releases. My primary
motivation was to give a hand to all those whose skills do not include
software development, without expecting anything in return. But apart
from that I also think accompanying each release with a Mac and
Windows binary will eventually help keeping the project alive and
vibrant.

Allard


On Nov 15, 2:07 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> 2009/11/15 Harry van der Wolf <hvdw...@gmail.com>

[Harry van der Wolf]

2009/11/16 allard <a...@allardkatan.net>

Okay, before people start speculating about how I feel about Yuv's
comments on my installer or grossly misspelling my name (en dat van
een landgenoot, Harry!) maybe I should step in.

Hi Allard,

 

You are right. I'm sorry. I must have had a massive blind spot. I have seen your name many times and still misspelled it.

 

My last reaction: It's the first time I actively participated in a flame like discussion like this and for a good reason, but I made the same misstakes I have seen so often.

I'll step out of this discusion.

 

Harry

[Jeffrey Martin]

sorry, I don't have a compiler.

That might not mean i'm useless, though ;-)

[Jeffrey Martin]

On Nov 15, 12:44 pm, Stefan Peter <s_pe...@swissonline.ch> wrote:
> As I have mentioned in another thread, hugin is not about market share
> or world domination.

Providing 90% of the computer users out there with a usable installer
for this program isnt' "world domination". It's common sense.

As I said already, do you want more people to help develop hugin?
offering them a way to actually USE the program (without spitting
vitriol about how they should compile the damn thing themselves) is
probably a good first step, no? :-)

Just because it's open source doesn't mean it should be intentionally
difficult to even try the product (yes, product).

[michael crane]

I does seem really a lot of work to try to get all the stuff to work
properly on windows.
I appreciate it is ( or used ) to be difficult to get any useful
information from microsoft but is there any way the process could be
simplified. I don't understand coding at all except for reading the
odd config file but is there not a list of substitutes so the building
works on windows. I'm loath to dive in because it seems at present
somebody spends hours changing one or two lines getting something to
work then it gets changed and they have to start again ?

regards

mick


2009/11/16 Jeffrey Martin <360c...@gmail.com>:

> --
> 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 hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Oskar Sander]

Thanks for your Windows build Allard!  I'm using it currently (alternating with Yuv's layout-branch test build) and it works great so far for me.

I think it is good to get something "out there" for windows like you've done, and then we can perfect the releases based on that.  The wiki and knowledgebase are growing, and the threshold for building is getting lower from each step.

I think the Hugin's new release model is great, not least because put's the issue about Windows builds in stark light. 

Cheers
O

2009/11/16 allard <a...@allardkatan.net>

--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
/O

[Bruno Postle]

2009/11/16 Jeffrey Martin <360c...@gmail.com>:

>
> As I said already, do you want more people to help develop hugin?
> offering them a way to actually USE the program (without spitting
> vitriol about how they should compile the damn thing themselves) is
> probably a good first step, no? :-)

No-one here is saying that users should compile Hugin themselves, and
Yuval certainly isn't saying that. I don't think users on Linux should
be compiling it either.

I could probably buy a copy of Windows and create a Hugin installer,
but since I don't use Hugin on Windows that installer would get
absolutely no QA. The installer needs to be maintained by somebody
who uses Windows*, this is why every time somebody asks for a Windows
installer we say "sorry there isn't one, would you like to take charge
of it?".

* though the .exe files could be cross-compiled on Linux with mingw,
this would have a number of advantages.

--
Bruno

[Jeffrey Martin]

OK, That makes sense Bruno, thanks for the detailed passionless
explanation. :-)

I'll keep my eyes out for this person.

On Nov 16, 2:00 pm, Bruno Postle <brunopos...@googlemail.com> wrote:
> 2009/11/16 Jeffrey Martin <360cit...@gmail.com>:

[prokoudine]

On 10 ноя, 13:45, namklim <namk...@googlemail.com> wrote:

> To me, GIMP seems much more professional in distribution of binaries.

Native (no X11) 2.6.7 binaries for Leopard/Snow Leopard anyone? :)

Sorry, I couldn't resist :)

Alexandre

[Dale Beams]

Hugin windows packagers need to look at what other projects are doing for packaging.  Gimp is a good start.  I know this subject came up when working with gramps-project.org.  At the time it was considered bad etiquette bundled other open source software with the same project, however I think that has began to change.  One installer we had looked at was the nullsoft installer.

Another avenue is for hugin to officially recognize a company that is willing to build the windows binary, much the same way other oss projects, such as kexi, etc. are doing.  The company that builds the binary charges x amount of dollars for the year support and binary download.

Dale

---

Hotmail: Trusted email with powerful SPAM protection. Sign up now.

[Erik Krause]

Harry van der Wolf wrote:

> It's not about the discussion itself or how it got here. That is completely
> valid here and your criticism as such is also valid. It's more the "choice
> of your words" that made me react ("self appointed leader" and so on), which
> is unfair and doesn't give Yuv the credits he deserves.

You are absolutely right. My anger threw me off.

[michael crane]

well I'd be thrilled to contribute and I do use windows. actually I've
been going off it lately but I imagine it's cyclical.
What I would require is a crude explanation what is and how works C
and what is C ++ how is the same name for program language different
in windows and unix. I would need to know what these differences are
before I dived in and tried to figure stuff out
mick

2009/11/17 Erik Krause <erik....@gmx.de>:

[Ryan Sleevi]

> well I'd be thrilled to contribute and I do use windows. actually I've
> been going off it lately but I imagine it's cyclical.
> What I would require is a crude explanation what is and how works C
> and what is C ++ how is the same name for program language different
> in windows and unix. I would need to know what these differences are
> before I dived in and tried to figure stuff out
> mick

Not to discourage anyone from contributing, because it's always welcome, but
it's important to understand that the lack of Windows binaries is not solely
related to 'the lack of someone to compile them,' which I think is what Yuv
was getting at originally before the flame war erupted.

What is needed is someone to do for the Windows side what Yuval (previously)
did for the general releases: Someone who can shepherd the platform,
maintain it, and support it. For example, what happens if someone has a
crash that is only on Windows? Who will be responsible for tracking it down,
getting diagnostic information, etc? Who will maintain the installer,
ensuring everything gets put in its proper place? And let's not forget
dependencies - and all their myriad configurations. When development
progresses, will the person building binaries have the necessary knowledge
and skill to keep their environment up to date - and to ensure that when
it's prepared for end-users, it's kept as simple and clean as possible?

There has definitely been a lot of interest in getting Windows compiled -
which is great, as it's a good beginners step into this. However, judging by
the questions on the list so far, it doesn't seem like (and I hope I'm not
offending anyone when I say this) that no one who has stepped up really
understands what the challenges were and are, and that the same quality
concerns may persist once your first 'hugin.exe' is sitting in your output
directory.

I've seen suggestions about possible installer scripts and the like - except
there is already an installer script that, while valid for 0.7.0, definitely
needs polish and attention. I've seen a lot of questions about dependencies
and compilation bugs (on all platforms, for that matter), when many of the
questions are already answered on the Wiki. While yes, I'm aware that sounds
dangerously close to the anti-user "RTFM", it really cannot be understated
how important that step is.

In terms of what has (historically) prevented a 0.8.0 release, consider the
following:
- No one has stepped up to own the installer. A huge amount of work is
already done, but there is still significant work to be done to put together
an end-user-friendly, international-law-abiding installer.
- No one has stepped up for the 'cat herding' task of building a plan for
how a Windows release might go. Once the binaries are built (which, not to
insult anyone, really is the easiest part), how will they get tested on the
various platforms? How will feedback be collected? How will issues be
addressed - Windows specific issues, installer issues, platform issues?
- What about 32-bit and 64-bit binaries? They *are* different, they *do*
have different build steps and, while their dependencies are the same,
actually resolving those dependencies requires quite a few different steps.
For Linux and Mac this is much easier, but on a platform like Windows, with
a build system like CMake, a compiler like MSVC, and a (justifiable) policy
of static linking, this is a whole new set of challenges.
- How will the exes be 'audited'? Consider that in the case of Linux, you're
often building from source or seeing it distributed by your distro vendor -
which is a nice clean audit trail of "no back doors". For Mac and Windows,
when shipping binary versions, there is a matter of trust - trust which
takes time to establish (as Harry has). Certainly that needs to be a
consideration, even as a community with no specific liability.

For those who are realizing that this task is a lot larger than perhaps
they'd realized, or that it involves a set of skills that they may not
necessarily have, don't be disheartened - there are still ways to
contribute. Testing and feedback will always be a necessary part, just as
interface design and behaviour will be important as well.

While I can understand how Yuval's message seems to have got lost or
misinterpreted, I would absolutely agree with the concerns he expressed on
his personal page regarding the significance of this task, and why it is
frustrating when people are frequently asking on list. It's not that there
is anything wrong for asking, it's just that it's not nearly as simple as
people may think it is, and it's misguided and potentially insulting to
insist that it is, as some have in the past.

[Henri Chevallier]

Thanks Ryan for explaining all that is involved. Indeed it looks like it's not just a problem of compiling Hugin on your own computer...

--

[allard]

Great explanation, Ryan.

[Harry van der Wolf]

Hi all,

 

@Ryan: Thanks for bringing this topic as such back in a constructive way.
One remark though on the section below, which "slightly hurt" me as OSX builder :-)

I think this also accounts for the new OSX builders but this time I only speak for myself.

2009/11/18 Ryan Sleevi <ryan+...@sleevi.com>

- What about 32-bit and 64-bit binaries? They *are* different, they *do*
have different build steps and, while their dependencies are the same,
actually resolving those dependencies requires quite a few different steps.
For Linux and Mac this is much easier, but on a platform like Windows, with
a build system like CMake, a compiler like MSVC, and a (justifiable) policy
of static linking, this is a whole new set of challenges.

When you compile hugin only for your own mac, so no distribution, you are right: it is much easier like building on linux.

To build a bundle on OSX for publication and release, we need to cross-compile for ppc architecture and i386 architecture. After compiling,  these binaries are merged, to create so called Universal binaries and libraries. This due to the fact that Mac was based on ppc and is now moving to the intel platform. All universal binaries though should be able to run on both platforms. When compiling for the new 64bit architectures as well, we cross-compile for ppc, i386, x86_64 and ppc64 and merge these four binaries and all libraries (also the underlying dependency libraries). MacOSX is the only platform that comes with merged multi-platform binaries/libraries.

To be able to build on Leopard (10.5.x) and make it work on Tiger (10.4.x), we also need to twist the Posix_2003 compliancy, which limits you by default to only build for your own OS version (For example: This is also why every Ubuntu or Fedora (sub-)version need a new Hugin build). We can "trick" gcc on MacOSX to build for multiple OS versions, but this is an active configuration action.

 

All this can't be done by cmake so therefore we use XCode, the MSVC counterpart. We also need quite some shell scripts to "knit" the (c)make/autoconf and XCode "ends" to each other.

Next to that: OSX uses "install_names" which means that the path to a library or binary is hard-coded into the library/binary. So inside libpng, you will find the path to libpng itself, but also to libtiff and libjpeg and others. When building for a bundle, all these "install_names" need to be rewritten to point to internal paths inside the bundle where binaries, frameworks and libraries all reside on different locations. This enables you to build a "self-contained" bundle but at the same time it also complicates the build process quite a bit.

Cross-compiling and merging, overcome OS level boundaries and these "install_names" is what really makes it complicated on OSX.

This is also why it takes some time to train a builder on OSX.

I only wanted to make everyone more aware of this complexity on OSX.

I mentioned in an earlier mail:

"I asked for Hugin OSX builders in my recent "Hugin OSX publication" mails. Three of them reacted on that and are now learning to build a bundle where one of them is ready IMO to release his own bundle now."

So this mail is also to give them the credits they deserve.

Kind regards,

Harry