• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    November 2008
    M T W T F S S
    « Oct   Dec »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
  • Archives

Cmake Help for Windows


cmake logoHugin uses the Cmake cross-plattform build system. It is an amazing tool that helps build the same codebase on different platforms. It is powerful and in concept relatively simple, but the details of the building process can be quite tedious and the printed documentation is steep.

The online help that comes with Cmake is helpful, but require command line typing which is not that practical when concurrently editing the CMakeLists.txt files in a text editor.

Introduce CMake Help, a simple and neat graphic user interface that will parse the Cmake online help and display it nicely in a window. Written initially by Aleix Pol and released under the GPL, it has been visually improved by Aurélien Gâteau. Both versions work nicely in Linux but not in Windows, because the line ending character in Windows is CRLF (actually two characters), while it is LF in Linux (and CR for the Mac).

I quickly fixed Aurélien’s versions to work in Windows:

  • Download and install Python for Windows. Version 2.5.2 works for me.
  • Download and install PyQt for Windows. Version 4.4.3-1 works for me.
  • Download and uncompress the cmakehelp archive. You may need 7-Zip in the process.
  • Doubleclick on main.pyw to start.

I hope you find this helpful. Happy Cmake-building!

5 Responses

  1. Regarding Windows Hugin builds, I’ve tried with the 0.7.0 sources and instructions in the wiki and FAILED :(
    Sorry but I suspect that those instructions are quite outdated.

  2. @pabloj: congratulations on trying, thanks for the hint about the wiki build instructions.

    The instructions are indeed slightly outdated since the introduction of new dependencies with the Google Summer of Code 2008 projects. They work for revisions prior to 3479 / October 8 2008. I’ve updated the instructions to reflect this information.

    Specifically for the situation you describe: right-click on the huginbase/hugin folder. In the context menu select TortoiseSVN -> update to revision… and enter the revision number 3478. Make sure the radio button is set on Revision rather than on HEAD revision and click OK.

    For later revisions, you’ll need an updated SDK which is not yet available.

  3. Sorry, I meant that the wiki needs more love, it’s not only technically outdated as you said, right now there are other problems:

    1. Notes about cmake 2.4.8 or 2.5/2.6 are outdated, the download link should be http://www.cmake.org/cmake/resources/software.html (no need to point to 404 or binaries)

    2. Build enblend 3 from CVS, do we really need this? There is an official release of enblend 3.2 of September 9, 2008 can’t we use that binary or just compile the official release?

    3. I suspect lcms is another dependency not mentioned

    Regards

    pabloj

  4. @pabloj: You are warmly encouraged to give the wiki the love it’s deserve.

    There you can either discuss pages (like you are doing here) or modify them directly (if you feel safe enough).

    Specifically to your three points:

    1. I would just edit it right away and mention that the instructions refer to / were tested with a particular version of cmake. If it works with a newer version too, mention it.

    2. Until the official release of enblend 3.2 there was no enblend binary compatible with hugin other than CVS. Mentioning the new alternative is an option now. I would leave the build instruction so that the reader has a choice.

    3. lcms comes pre-compiled with the hugin SDK.

    Both, points 2. and 3. raise the more general question of pre-packaging vs. self-build. Downloading pre-compiled packages is convenient, but sometimes they lack the features required by the bleeding edge. We play the trade-off by building packages with critically important features from SVN/CVS and packaging relatively stable and less critical feature in the SDK. If you don’t want to rely on the SDK, there are more complex in-depth instructions (which are even more outdated).

  5. You are simply not going to turn that wiki page into something usable by everyone, aren’t you?

    I don’t feel safe enough to edit the wiki, I’ve not even been able to go through the whole compilation, otherwise you’d have found a post in my blog about that.

    Right now compiling a source release of Hugin (not a bleeding edge cvs checkout) is not for everyone, also, I think that a release has to be built on released software (if possible, right now it’s possible to avoid referring to cvs for enblend/enfuse).

    I’ve successfully compiled Gimp and PostgreSQL and I have to say that it was really easy, can’t say the same for Hugin and the more I go into this the less I understand your attitude in that post about the lack of volunteers for a “simple task” like compiling a windows version of Hugin.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s