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 [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 -~----------~----~----~----~------~----~------~--~---
