Hallo Guido,
schoen Dich wieder zu sehen!
Guido Kohlmeyer wrote:
> 1. Pre-build package to give an easy starting point to build hugin from
> scratch.
> 2. Update mechanism to keep up with hugin development branch.
To be really perfect the updated mechanism should keep up with *any*
state of Hugin and match a combination of "branch" and revision number.
(I prefer to call it a "codeline" - to branch is for me the action of
splitting one codeline from the other).
> 3. Good documentation of the SDK to simplify the maintenance of the SDK. A
> hand over to another person in charge can be easily done.
>
> Requirements 1 and 2 contradict slightly and this is mainly the reason why
> Yuv and I have different point of view about the SDK. Neither of us is
> really wrong.
There is no contradiction in the requirements. There is some difference
in the objectives, which I see as the complementary ends of a single
range rather than as conflicting / excluding each other.
To my understanding, you want to build a stable release. Or maybe a
development snapshot based on stable SDK and bleeding edge Hugin. I want
the most bleeding edge combination of upstream dependencies and Hugin.
It's mostly a difference in purpose, mechanism are roughly the same
(except some details such as fetching pre-built binaries or tarball
releases or repository snapshots).
a. Stable Hugin against stable SDK => public distributed releases
b. Bleeding edge Hugin against stable SDK => testing snapshots
c. Bleeding edge Hugin agains bleeding edge SDK => developers feedback
(a) and (c) are the two extremes of the range, while (b) is the middle.
With requirement 2 above (which makes it even better) we add a different
dimension (and an important one): time. You will make it possible to
follow the evolution of the a-b-c range over time.
The reason why I am so keen on (c) is because it lays in the future. It
gives us early warning when an upstream change affects Hugin. And it
gives us the possibility to feed back to them. It's a development and
communication tool, the first goal of which would be to help push
upstream what is currently in foreign.
And (a) is what I recommend for the general public, to be used in a
production environment.
Some users are keen on (b) and that's good too, because this is where we
get most bug reports from.
> I thought about an automated SDK builder, like Ryan already mentioned
> about. Some kind of batch script which loads the packages e.g. using wget,
The script would have to discern the four categories of packages I
described earlier:
- (F)IX: has not been changing for years and is unlikely to change any
time soon (e.g. GetText)
- (S)TABLE: evolves regularly and is worth updating to the latest
stable, but is not critical (e.g. Boost)
- (D)YNAMIC: evolves continuously and is worth updating continuously
(e.g. ExifTool)
- DE(V): is critical to bleeding edge Hugin functionality, and it is
worth following it in between releases when making test builds (e.g.
libpano or Enblend and Enfuse)
We'd need three fetching ("loading") mechanisms:
1. binaries - preferred for (F),(S),(D) packages when building target
(a) *if* the upstream dependency provides binaries that are known to work.
2. tarballs - alternative for (F),(S),(D) packages when building target
(a) and patches need to be applied. Also preferred for (V) when building
target (A)
3. repository - alternative if no tarballs are published; or if we need
a feature that is in between releases (e.g. Hugin-0.7.0 that needs
Enblend-3.2 but there was no Enblend-3.2 at the time of the 0.7.0
release). This would also be the preferred way for (V) packages when
building target (b); and the preferred way for all packages when
building target (c).
> The documentation is mandatory, thus you can read what's going on during
> build of the SDK.
very good point.
> The script can be
> stored in the hugin repository and therefore it will be possible to build
> past versions of the SDK and hugin as well.
very good point. One of the problems now is the disconnect. The .iss
files for the installer are from the 0.7.0 beta / RC time. There are
modified versions around but I don't know where they are nor who has the
last ones. They need to be synchronized against the result of the script.
The build script itself (once the SDK is in place) has been already
posted here by Ad in the past. I don't know if he has improved on it.
We need to keep all of these scripts and files in sync and a repository
is the way to go. This could be a folder in Hugin's SVN repository, or
it could be a new repository. I was going to open a Mercurial (Hg)
repository in the Hugin project to learn it and understand its features
and limitations. Enblend has already migrated to Hg. Maybe it would be
an idea to put the Windows SDK + Build work in one such Hg repository?
Yuv
--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
