> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Tom Glastonbury > Sent: Monday, May 17, 2010 6:26 AM > To: [email protected] > Subject: Re: [hugin-ptx] Re: Windows 64-bit Build > > Hi Ryan, > > Thanks for all that info - I'll digest it and do some research. One > comment re NSIS - I certainly wasn't thinking of using it for building, > but more in response to Yuv's note about downloading dependent > source/binary packages. Windows doesn't come with wget as standard, and > I'm not clued-up on some of the more enterprise-oriented scripting > stuff > that later versions of Windows support, so I was thinking that NSIS > would be a useful tool for managing these downloads and for generally > bootstrapping the installation (but not the build) of the SDK without > requiring the user to download and install several utilities by hand in > advance. >
Have you worked with NSIS before? It's more akin to assembly language than it is a generic scripting. Registers and stacks make up the core language, and it's frustratingly limited. The support for downloading files is rudimentary, and the selection of compression algorithms is limited (which would affect the source downloads). My comments about Python/Perl earlier were meant to demonstrate that it's arguably perfectly reasonable to have some minimal set of dependencies (perhaps even distributed with the file): ex, you need wget and python, and here's the executables, as well as the python script that does the work. Or batch, or what have you. As it relates to the SDK, there isn't much dependency management that needs resolution: If you're going 32-bit, you need packages X, Y, and Z, and if you're wanting to compile 64-bit, you equally need packages X, Y, and Z. The only variation is if you're also wanting to compile enblend/enfuse, as then you'll also need packages A, B, and Z. There is question, at this point, whether that rightfully composes the Hugin SDK or not (really, it's just useful because of the overlap) I don't want to discourage you from pursuing something you're comfortable in, I'd just suggest that NSIS wouldn't be the right tool for the job, which is something Yuv also echoed. Can it be made to do what you want? Possibly - but my own experiences with NSIS tell me it'll be a bit messy. > > Another note: As it stands, there are a few patches required to 3rd > party libs that go beyond .sln file mods, and actually touch source > code. From what various people have said, and the convention in use for > the do-it-yourself SDK, I understand that the desired option is to > download the unmodified source code of a specific version from a given > library's main repository, then apply hugin-specific patches if needed. > Is there general agreement with this (or at least lack of > disagreement)? That's the best strategy, IMO, as it allows for flexibility to change/update the library in the future, and hopefully eliminate the patches once they become unnecessary (most are minor, I think the closest anything gets to 'major' is just patching the wxWidgets config for third-party libraries) -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
