Re: [hugin-ptx] Re: Package manager for windows
On Fri 27-Nov-2009 at 16:40 -0500, Nicolas Pelletier wrote: > >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. I don't think there is any alternative to the SDK for developing Hugin on Windows. The alternative of cross-compiling with mingw is very attractive for creating binaries for Windows installers - You get a traceable provenance for all components. Potentially it would also be possible to create a fully automatic nightly build for download, with the fedora mingw tools compilation is done in a Linux chroot so it would be very difficult to break the build-server. -- Bruno -- 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
Re: [hugin-ptx] Re: Package manager for windows
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 : > 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 > 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 >> 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 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 > > -- > 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 -- You received this
Re: [hugin-ptx] Re: Package manager for windows
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 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 > 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 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 > -- 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
[hugin-ptx] Re: Package manager for windows
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 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 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
[hugin-ptx] Re: Package manager for windows
Nicolas Pelletier schrieb: > Maybe there is something I originally did not understand. > > I'm looking more into the compile time dependency than the run time... > aka I want to build enblend. I pull the source. First thing I see is > that I'm missing wxwidgets, lcms, the tiff library, etc... > > Does the package manager handle this? Yes, it does. If you want to see the dependencies for enfuse, point your browser to http://packages.ubuntu.com/karmic/enfuse where most of the information relevant for this package are displayed. However, the power of a package manger only can be estimated when working with it for some time. The relations between the gazillion packages results in a system that recommends additional installs or removes if you decide to install or remove a single package. of course, you still can shoot yourself in the foot by requesting, let's say a system without kernel. > The reason I ask is that I'd like to get a dev environment setup, and > help simplify the process for the next people who would like to. I think > the SDK is nice as long as we have a core of people keeping it up to > date which seems to be problematic now. So maybe another solution, or a > hybrid solution could be done. Yes, this is one of the problems. From the quality managers point of view, you shall not distribute binaries that contain unstable or, even worse, untested components unless we are talking about a release candidate. From the power users point of view, only the latest cutting edge version is interesting. Support is expected to handle any upcoming issues, at least in a commercial projects. Developers normally don't want to be involved in this process: If it compiles and solves the test case, it's history and one can move forward to solve the next issue. Yuval has introduced the guidelines for the SW development (see http://wiki.panotools.org/Development_of_Open_Source_tools), if I got this right. This is an invaluable tool because it introduces the formal way to get a stable and reliable SW distribution. However, it should not end there. The process of building binary distributions (for whatever OS you care for) is not defined in the same consequence as the development of the hugin sources is. Because hugin relies on external projects (enblend/enfuse, autopano, ...) and a plethora of libraries, all of those being OSS projects themselves, the definition of a binary release can not stop with the version of the hugin source used. What is missing, from my point of view and for all non linux versions, is the inclusion of all third party projects into the equitation. Declaring a release candidate should include the definition of all third party projects and their version to be included in the final binary. This should result in a "stable" SDK" that serves as the base for the binary release. Of course this won't work for linux distributions as they have to match the hugin requirements with the requirements of the rest of their packages. But the linux distributions do not seem to be the problem here, mostly because they are prepared by the specialists of the distributions themselves and undergo some rigid testing prior to the release. > If there is a file that contain the list of what is required (lcms, > wxwidgets, boost version X, etc) that is used by the package manager, > maybe there is a way to reuse that information to at least provide a > checklist to the user of what is required; and the best solution would > be to automate the pulling of those packages. As it is at the moment, the files containing the dependencies of hugin are the cmake definition files. But those mostly don't include the version info, so your mileage may vary. This is the point where the SDK idea entered the picture: It will ensure that your hugin build is matched with the appropriate dependencies versions. Regards Stefan Peter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Package manager for windows
I'm not exactly a professor on this subject either, but from my understanding (and experience), package managers are mostly for binary releases, in other words: the runtime dependencies. I'm not aware of a package manager for build time dependencies. These are generally different from runtime dependencies, e.g. libtiff is needed to compile Hugin, but not to run it (if everything gets linked statically). If you want to know the build time dependencies, you can look up the list at the wiki pages mentioned earlier. I'm not sure if you can *easily* extract the list from the Hugin sources (makefiles, cmake files), but it should be possible, since libraries need to be linked, and the instructions to do so need to be available. I do like your idea of automating the process of downloading and building external dependencies. In fact, it should be possible. The mingw-cross-env approach I'm figuring out in another thread [0] does this more or less, but for cross building from Linux (host) to Windows (target, for the binaries). In the .mk files you can specify the dependencies, which will be downloaded and built automatically if they don't exist already. Currently that system is targeted at libraries, not at complete programs like Hugin, but the system can already be "hacked" to work for programs too. You only have to make sure that the files which are built aren't automatically destroyed but are copied to a safe location, that's all. Or have mingw-cross-env build the dependencies and work out Hugin by yourself, which is what I'll be trying to do. If you want to build on Windows, for Windows, I cannot help you, because I haven't tried. You hinted you found some "package managers" for Windows, but didn't say which ones? Maybe others can help you with that. By the way I disagree with Lukas and Peter on having to use an external tool or package manager. Microsoft just "forgot" to include a proper solution for package management *completely*, so why not use an external tool? Microsoft didn't supply CMake either, but I don't hear anyone complaining about that... If a package manager can become an integral part of a fully automated build chain, why not? I think this would be a great thing. [0] http://groups.google.com/group/hugin-ptx/browse_thread/thread/935d140fa7dc80df/b7e74c081252a6b3#b7e74c081252a6b3 -- Bart --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Package manager for windows
Maybe there is something I originally did not understand. I'm looking more into the compile time dependency than the run time... aka I want to build enblend. I pull the source. First thing I see is that I'm missing wxwidgets, lcms, the tiff library, etc... Does the package manager handle this? The reason I ask is that I'd like to get a dev environment setup, and help simplify the process for the next people who would like to. I think the SDK is nice as long as we have a core of people keeping it up to date which seems to be problematic now. So maybe another solution, or a hybrid solution could be done. If there is a file that contain the list of what is required (lcms, wxwidgets, boost version X, etc) that is used by the package manager, maybe there is a way to reuse that information to at least provide a checklist to the user of what is required; and the best solution would be to automate the pulling of those packages. If some of my assumptions are wrong, don't hesitate; I'm new to a lot of this. nick On Wed, Nov 11, 2009 at 3:51 AM, Stefan Peter wrote: > > Nicolas Pelletier wrote: > > Hi, > > > > 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? > > I don't think that a packet management system that is not part of the > operating system is of any use. > > I think that one of the big problems is autopano-sift-c. Being > encumbered by a patent, it should not distributed with hugin. On the > other hand, hugin requires a control point generator. > > Another issue is enblend/enfuse. As long a no fine 4.0 is released, we > should 3.2 IIRC. > > So, maybe a modular installer will help? Breaking the monolithic windows > installer into sub projects (hugin-gui, hugin-tools, enblend/enfuse, > autopano-sift-c, ...) that could be maintained independently but tied > together for building the final hugin installer? But then we'd need even > more maintainers from the windows camp ... > > > > > Also, in linux, what file is used to find the required packages? I.e. > > what file contains the dependency? > > > There is no single file IIRC. And the whole process with all > dependencies is documented on > http://wiki.panotools.org/Hugin_Compiling_Windows and > http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK > > We currently have a binary for the 2009.2.0 release. What is needed is a > volunteer that repeats this for the 2009.4.0.rc2 so the process is > stable once 2009.4.0 is released. And, if there is enough time and urge, > a 2009.2.1 version that fixes some issues may be a prudent thing to do, > too. > > Regards > > Stefan Peter > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Package manager for windows
Nicolas Pelletier wrote: > Hi, > > 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? I don't think that a packet management system that is not part of the operating system is of any use. I think that one of the big problems is autopano-sift-c. Being encumbered by a patent, it should not distributed with hugin. On the other hand, hugin requires a control point generator. Another issue is enblend/enfuse. As long a no fine 4.0 is released, we should 3.2 IIRC. So, maybe a modular installer will help? Breaking the monolithic windows installer into sub projects (hugin-gui, hugin-tools, enblend/enfuse, autopano-sift-c, ...) that could be maintained independently but tied together for building the final hugin installer? But then we'd need even more maintainers from the windows camp ... > > Also, in linux, what file is used to find the required packages? I.e. > what file contains the dependency? There is no single file IIRC. And the whole process with all dependencies is documented on http://wiki.panotools.org/Hugin_Compiling_Windows and http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK We currently have a binary for the 2009.2.0 release. What is needed is a volunteer that repeats this for the 2009.4.0.rc2 so the process is stable once 2009.4.0 is released. And, if there is enough time and urge, a 2009.2.1 version that fixes some issues may be a prudent thing to do, too. Regards Stefan Peter --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Package manager for windows
Hi, 2009/11/11 Nicolas Pelletier : > 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? If it needs some additional software then it's IMO not solution. > Also, in linux, what file is used to find the required packages? I.e. what > file contains the dependency? > Thanks, > nick There's no "common consensus". Every distribution has it's own package manager (more exactly there are two main managers used on most distros) so compiling and handling of the dependencies is on the developers of the distribution (because eg. the names of packages are different). > > > Lukas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
