Or we can go the easier route (for end users) that I've been pursuing: An "automatable" that handles it all for you ;-)
With the basic pre-requisite of 1) Sources for packages 2) The patches from me (already applied, but nothing to say we can't automate that in the future) 3) MSVC Express Edition 4) Windows SDK (6.1 or 7) It digs in and builds each part of the SDK - Debug & Release, 32-bit and 64-bit. I'm currently using batch files as the means, but after working with the CMake-ification of Enblend/Enfuse, I think there is enough capability (by means of the external commands) that for the non-CMake'd portions (eg: Everything *BUT* enblend/enfuse), we can call the appropriate tools (eg: configure.bat for STLport, bjam for boost, vcbuild for the various .sln based projects, etc). With my batch file setup, I've got it automatically building everything through enblend-enfuse hands-free. Using the four basic requirements above, I can kick it off, and step back and I've got all the enblend-enfuse binaries. At that point, the "distribution" of the SDK needs merely concern itself with the maintenance of 1) The patches - Which tend to fix path resolution issues relative to the SDK for .sln projects and add 64-bit configurations 2) The CMake configuration script - Which is used really just to "find" the various packages, determine if they're built yet or not, and if not, build them using the packages appropriate build mechanism. This seems a much more realistic and reasonable scenario for getting people started, and also resolves potential issues where, for example, a user might want to alternative between statically and dynamically linking the MSVC runtime (Legal concerns, performance concerns, functionality, who knows) and issues w/ versions (eg: 2008 v 2008 SP1 v 2010 at some point) Thoughts? > -----Original Message----- > From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On > Behalf Of Yuval Levy > Sent: Thursday, September 10, 2009 12:16 PM > To: hugin-ptx@googlegroups.com > Subject: [hugin-ptx] Windows Hugin SDK and documentation > > > Hi Ryan and other Windows developers > > I'm moving this piece of information to the main mailing list. > > > Ryan Sleevi wrote: > >> -----Original Message----- > >> From: Yuval Levy > >> Sent: Tuesday, September 08, 2009 8:34 AM > >> To: kornel.be...@berlin.de > >> Cc: Harry van der Wolf; Christoph Spiel; ryan+hugin; > >> bst; Thomas.Modes; Andrew Mihal; Lukáš Jirkovský; Bruno > >> Postle; Pablo d'Angelo; Pascal Spörri > >> Subject: Re: cmake compilation of enblend [was: Enblend bug tracker > and > >> developer mailing list] > > <SNIP> > >>> OK, so we may create something working on more then one platform. > >> reminds me that I did not yet even try on Windows. I'm stuck with > not > >> being able to build lcms-1.18a inside the Hugin SDK (which has > 1.17). > > > > Yuv, check the .diff file uploaded to the Wiki for building the > > Windows SDK. It's just a one line change for lcms (1.18). The trick > > for lcms-1.18 is that you *only* need to build the lcms project, not > > the entire solution. lcms (the project) doesn't depend on the TIFF > or > > JPEG libraries, so it should have no trouble building. > > Thanks, Ryan - this did the trick. > > I was going to add this bit of information, as well as document the > lack > of OpenMP support in the Express Editions of MSVC, to the page > documenting the [Hugin SDK]. > > Then I realized that I was going to raise a conflict again: There is a > major inconsistency in the document which stems from the definition of > "Hugin SDK". > > When writing up the document, Guido defined "Hugin SDK" as the "minimal > stable binaries and headers needed to build and run Hugin". > > To me it must be more than that. And to Ryan obviously too: lcms is not > needed to build the Hugin binary. Hence it is documented as "64-bit > Only". But as I found out, it concerns 32-bit as well. > > The logical consequence would be to first define what the Hugin SDK > really is; then to update the documentation and distributed binaries > accordingly. > > Ad's releases are to me the proof that the current SDK does not work. > It > becomes stale quickly as upstream tools and libraries evolve. > > Worse: it leaves people like Ad dependent on the next binary SDK > instead > of giving them the tools and knowledge to update their SDK. > > The [Hugin SDK] Wiki page should make people like Ad independent. > > Hence my suggestion: > > 1. The [Hugin SDK] will document how to build each and every package > upstream, including further upstream dependencies (e.g. Hugin depends > on > enblend; and enblend depends on lcms; hence both should be documented), > for both 32 and 64 bit. > > 2. Distribute the SDK in two forms: one large archive containing > everything (almost like the current one). It will become outdated, but > here comes the second distribution: archives of individual packages. > This way the faster evolving packages can be updated/distributed more > often. > > To achieve this, I suggest to expand on the current structure of the > [Hugin SDK]. Add/document the missing packages (currently if I try to > build enblend according to [build] instructions, I miss some bits). > > For each package, note if it is: > - FIX: has not been changing for years and is unlikely to change any > time soon (e.g. GetText) > - STABLE: evolves regularly and is worth updating to the latest stable, > but is not critical (e.g. Boost) > - DYNAMIC: evolves continuously and is worth updating continuously > (e.g. > ExifTool) > - DEV: 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) > > Currently there is too much confusion. There are four pages documenting > Windows builds. I would suggest integrating the information about the > [patches] into the [Hugin SDK] documentation; and extracting the > relevant information from the [incomplete] page. > > In the end, there should be just two pages: one guiding the complete > newbie through a simple [build] of the DEV packages (that's Hugin, > Autopano-SIFT-C, Enfuse-Enblend, Libpano) with pre-built SDK binaries; > and one documenting how to build the *whole* [Hugin SDK] from scratch. > > Yuv > > > [Hugin SDK] http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 > [build] http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK > [patches] http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29_Patches > [incomplete] http://wiki.panotools.org/Hugin_Compiling_Windows > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
