allard wrote: > Okay, either the make process went wrong or I messed it up when > merging changes. Probably the latter. The URL.txt still contains this: > "URL=http://www.photopla.net/hugin/dlcounter.php? > s...@hugin_wc_revision@"
@....@ in the repository are usually placeholders to be replaced by CMake at the time it prepares the source for the build. In this specific case I entered into the CMake code a little automation that takes the SVN revision number and substitute it for @HUGIN_WC_REVISION@ in many places (e.g. the "about" window). > One thing that should perhaps be changed in the SDK is that the > installer files are put into hugin_build/platforms/windows/installer , > and the files in hugin_build/INSTALL/FILES . But the installer script > refers to the file location as FILES/ , ie as if it was in the > 'INSTALL' directory. I just copied it there, which works, but is there > a reason why this is done? The installer files should be in hugin_build/INSTALL. If you have them in hugin_build/platforms/windows/installer it is a mix up between the source and the build environment. Best practice is to keep the source in a separate folder (the one you check out from SVN to) and do all changes that you need to do there. Then you can use diff (part of TortoiseSVN and any respectable SVN-client) to create patches against the SVN repository, and mange the differences. Use the hugin_build folder (that you specify when running cmakesetup.exe) only to click on the MSVC project and do the build; and to click on the .iss file in hugin_build/INSTALL to build the installer once the files in hugin_build/INSTALL/FILES are ready. Then test the installer. If you are not sure, ask a small circle of people to test it to avoid spreading confusion. Once you are sure, publish it to the world. "Sure" is a relative thing. The first step is to be sure that things build. The second step is to be sure that they install in the right place. The third step is to be sure that they are somewhat functional. The fourth step is to be sure that the details work as well. I usually published snapshot when they where between step three and four. I have a set of test cases, a few basic stitching scenarios with different source images on different location, and when my installer passes these basic tests, I set it free for more public/wider/deeper testing. In the past month or so I had issues with my SDK so that opening files from network drives failed. I think I have narrowed it down to my self-built Boost libraries (one of those mammoth parts of the SDK) but I am not sure yet. In any case my focus is on bleeding edge Hugin vs. bleeding edge SDK and I am happy to have help from somebody focusing on bleeding edge Hugin vs. stable SDK. If you have further questions, feel free to ask. Yuv --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
