I was confused about the SDK what exactly it was, how it ties in with the new stuff. I'm a semi literate luser ask me to test what you do mick
2009/11/27 Nicolas Pelletier <[email protected]>: > Thanks Tom. > It's never too late :P > Seriously, I was looking for options, in case there is a good one to replace > the SDK. The SDK is as good as the people maintaining it. So before I look > into doing so, I wanted to be sure there was not anything better. > My current conclusion is that SDK will stay, but if I end up building it, > the format will change. Here is what I have in mind (but always open to > comments... and I need to actually do it, for which I'm not too fast > lately). > The current SDK is dependant on 3 things being in sync: > - The SDK itself > - The instructions on the Wiki > - The source code (i.e. using the same dependencies as the SDK provides). > The sync not being perfect, it can be difficult for some users. It also > creates frustration. > I would therefore propose: > The SDK includes a readme with all the instructions, software to install, > how to fetch the hugin\enblend source, etc. > This would remove the wiki-SDK dependency. > I would also add that the SDK would stop being "current most up to date SDK" > but be more > Hugin SDK for Hugin Build XYZ and Enblend build ABC > The instructions would be very clear about which version to pull the source > from. > In theory, this would then remove the source code-SDK dependency as the SDK > targets a specific version. > This has a drawback, it will bring you as far as the SDK can, but not on a > branch, or the head revision. > I think it will be easier, and less pain for users to get here (and get the > satisfaction of a working build, of having accomplished something, and > getting some confidence about the process) and THEN get them on the head > revision. > So instruction could have a few more details about how to get the head and > try to build. And a few info about how to debug, and\or request help from > the list. > We could then provide a new SDK and have some input from the user about why > they were not able to achieve the last step by themselves, and provide > better input in the readme. > In short, I think if a user tries to build hugin and fails at step 1, they > will stop. > If they get it to work on a (slightly older) version after 9 steps, if then > they get into trouble, they will try to resolve it. > This is my current brain dump... any questions and\or comment welcome. Also, > I'm still extremely new here, any historical reasons for why something is > like this or that is also appreciated. > Thanks, > nick > > On Fri, Nov 27, 2009 at 1:37 PM, Tom Sharpless <[email protected]> > wrote: >> >> Nick, >> >> This may be too late, and maybe too simple-minded, but IMO there is >> only one practical way to install the dependencies for building hugin >> on Windows: the hugin SDK (http://hugin.panotools.org/sdk/MSVC/ >> hugin_enblend_sdk_msvc2008_v2.7z). That puts everything you need in >> one directory. If you would rather use "correctly installed" versions >> of some of those packages, you can then make the necessary >> modifications to the cmake scripts (and very possibly to the installed >> package's libraries) one package at a time, while being able to build >> hugin all the time. >> >> I am quite sure there will never be anything that can manage Linux >> packages well on Windows -- not only because of technical >> difficulties, the market is simply not there. >> >> Regards, Tom >> >> >> On Nov 10, 10:35 pm, Nicolas Pelletier <[email protected]> >> wrote: >> > Hi, >> > >> > Since building hugin on windows is not so trivial as on other platforms >> > (thanks to the package manager on linux), I was wondering a few things. >> > >> > A little researched showed that there are now a few package managers >> > that >> > work on windows. Has this been looked into as a solution for hugin? >> > >> > Also, in linux, what file is used to find the required packages? I.e. >> > what >> > file contains the dependency? >> > >> > Thanks, >> > >> > nick >> >> -- >> 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 > > -- > 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 -- 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
