Help\Question setting up dev instance

[Nicolas Pelletier]

Hi,

I'm setting up everything to build hugin following these instructions (http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK)

As I'm building enblend, it is obvious that the SDK linked in there and the source code for enblend don't match in regards to the dependency and the folder system. (i.e. boost is not in boost-trunk as in the SDK but in boost_1_39_0...).

I want to confirm if this is normal? or am I following the wrong instructions \ using an old SDK? Saw some older post mentioning a "new" sdk should correct some of these, but did not find it if it is out.

I've resolved all path but lcms.h which I don't have on my computer... yet...

Thanks,

nick

[RizThon]

I don't know if it's still the case, but as written in "[hugin-ptx] (Probably very basic) help needed for build process on WinXP: missing files?", at that time the current enblend didn't compile. So you might need to get revision 523.

[Yuval Levy]

If I am not mistaken, this has been fixed (thanks Thomas Modes).

and if I recall correctly, I explained in the thread mentioned by
RizThon how to resolve the lcms dependency.

Indeed, Nicolas, the SDK and the instructions are out of sync with the
current enblend development. Joachim is trying to synchronize them and I
mentor him.

I won't have access to my Windows box until Monday.
Yuv

[Nicolas Pelletier]

Thanks,

This is not the thread I had found and will follow that this weekend.

Thanks!

nick

[J. Schneider]

> Thanks,
>
> This is not the thread I had found and will follow that this weekend.

Fine, then we are two.

> Thanks!
> nick

regards
Joachim

[Nicolas Pelletier]

I'll try to update the wiki to at least redirect to the thread, if not mention what should be done until the SDK is update. If it can make life simpler for other people.

nick

[Yuval Levy]

Please do update the wiki. the thread is transient but there are some
learnings that should be made permanent in it.

Next time one dependency upgrades, the sync between the mercurial
repository and the SDK is likely to break again.

And changes to both repository and SDK can break the installer.

In Linux flavors all of these are taken care by the package manager that
defines build and runtime dependencies and that keeps track of which
files are intalled where.

In Windows the user is on their own, and this can be a frustrating
experience.

On the wiki page you want to describe how to diagnose such a break and a
generic way to fix it. Then you want to list all the specific fixes for
each and every SDK package. Together they will end up being an
instruction to build the SDK from scratch, though ideally users only
need small fixes for their existing SDK and the first user that bumps
into a break fixes it and contributes back to the project by updating
the fix into the wiki; and a zipped binary package too. The zipped
binary package can be used by other users to overwrite / update their
SDK without having to download a full SDK or going through the whole fix
as described in the wiki. When there are enough fixes to make the SDK
outdated (as it is now), a new version of the SDK can be packaged and
put up for download.

I'm sorry I can't do much more. Windows is no longer my main platform.
I'm currently very much behind on emails of this group, and have to
prioritize my limited time. I'm in Quebec-City until Monday and won't
have access to Windows until I'm back in the office. And I have a bad
surprise waiting for me there. I have not been able to access my server
remotely. It may just be a missed update of the dynamic DNS (the VoIP
infrastructure seems to be OK) but it could as well be a failed system
drive or a failed router.

Whatever it is, I have a couple of very busy days ahead. For Hugin, and
in the short term, this means:
- release RC2 (this weekend, from my dyno-book)
- take the time to read all the interesting things that have been
brought up in the GUI threads (likely one of next week quiet nights, if
there is any)
- understand what is wrong with my gettext implementation and fix it
(thanks Thomas Modes for the feedback)
- test (and possibly re-fix) a configuration error with the enblend
Mercurial repository (notifications are not yet 100% functional)
- last but not least, I am playing with SVN->Hg and back. My goal is to
piggy-back on the existing SVN infrastructure and use Hg locally. This
shall make developers life easy without disrupting anything downstream
(in my vision SVN will stay as-is for integration and release processes).
- oh, and I also have the "coding style" document, resulting from the
discussion amongst developers back in August, that is at 80% completition.

But first: it's 4h30 AM and its time for me to start my day.
Yuv