From: Tom S. <tks...@gm...> - 2010-01-16 04:14:53
|
Hi, At present, to build hugin it is necessary to copy headers and libraries from the panotools build tree into a different directory structure. That is because many hugin files use the form #include "pano13/xxxx", and there is no such directory in the panotools tree. The corresponding directory is called panotools/libpano. It would be better to use the panotools tree, as built, to build hugin. The simplest way to achieve that would be to change the name of panotools/libpano to panotools/pano13. Another possibility is to remove the directory prefixes from all those include statements in hugin. That is a bigger job and possibly tricky, for example: the hugin source tree actually contains two files called "panorama.h" that presumably should not be replaced by the panotools one; most references to those have directory prefixes (different from pano13/) but one just asks for plain "panorama.h" and would have to be qualified. I would prefer to leave hugin alone and rename the libpano directory to pano13. On the other hand, that might well break some other uses of libpano. Any ideas? Regards, Tom |
From: dmg <dm...@uv...> - 2010-01-16 04:22:37
|
Isn't that a problem of configuring the compilation environment? libpano installs in pano13. In my opinion that is the best place to do it. Hugin should have as includes #include "pano13/panorama.h" So hugin is doing it properly. What is happening is that your configuration should include as -I<location-where-pano13-dir-is-located> This should be done by CMake. --dg On Fri, Jan 15, 2010 at 8:14 PM, Tom Sharpless <tks...@gm...> wrote: > Hi, > > At present, to build hugin it is necessary to copy headers and > libraries from the panotools build tree into a different directory > structure. That is because many hugin files use the form #include > "pano13/xxxx", and there is no such directory in the panotools tree. > The corresponding directory is called panotools/libpano. > > It would be better to use the panotools tree, as built, to build > hugin. The simplest way to achieve that would be to change the name > of panotools/libpano to panotools/pano13. > > Another possibility is to remove the directory prefixes from all those > include statements in hugin. That is a bigger job and possibly > tricky, for example: the hugin source tree actually contains two > files called "panorama.h" that presumably should not be replaced by > the panotools one; most references to those have directory prefixes > (different from pano13/) but one just asks for plain "panorama.h" and > would have to be qualified. > > I would prefer to leave hugin alone and rename the libpano directory > to pano13. On the other hand, that might well break some other uses of > libpano. > > Any ideas? > > Regards, Tom > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: dmg <dm...@uv...> - 2010-01-16 04:30:50
|
oh, I think I get it. Are you installing libpano? only when it is installed, the pano13 directory is created. --dmg On Fri, Jan 15, 2010 at 8:22 PM, dmg <dm...@uv...> wrote: > Isn't that a problem of configuring the compilation environment? > > libpano installs in pano13. In my opinion that is the best place to do it. > > Hugin should have as includes #include "pano13/panorama.h" > > So hugin is doing it properly. > > What is happening is that your configuration should include as > -I<location-where-pano13-dir-is-located> > > This should be done by CMake. > > --dg > > > On Fri, Jan 15, 2010 at 8:14 PM, Tom Sharpless <tks...@gm...> wrote: >> Hi, >> >> At present, to build hugin it is necessary to copy headers and >> libraries from the panotools build tree into a different directory >> structure. That is because many hugin files use the form #include >> "pano13/xxxx", and there is no such directory in the panotools tree. >> The corresponding directory is called panotools/libpano. >> >> It would be better to use the panotools tree, as built, to build >> hugin. The simplest way to achieve that would be to change the name >> of panotools/libpano to panotools/pano13. >> >> Another possibility is to remove the directory prefixes from all those >> include statements in hugin. That is a bigger job and possibly >> tricky, for example: the hugin source tree actually contains two >> files called "panorama.h" that presumably should not be replaced by >> the panotools one; most references to those have directory prefixes >> (different from pano13/) but one just asks for plain "panorama.h" and >> would have to be qualified. >> >> I would prefer to leave hugin alone and rename the libpano directory >> to pano13. On the other hand, that might well break some other uses of >> libpano. >> >> Any ideas? >> >> Regards, Tom >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> PanoTools-devel mailing list >> Pan...@li... >> https://lists.sourceforge.net/lists/listinfo/panotools-devel >> >> > > > > -- > --dmg > > --- > Daniel M. German > http://turingmachine.org > -- --dmg --- Daniel M. German http://turingmachine.org |
From: Bruno P. <br...@po...> - 2010-01-16 13:22:12
|
On Fri 15-Jan-2010 at 20:14 -0800, Tom Sharpless wrote: > >At present, to build hugin it is necessary to copy headers and >libraries from the panotools build tree into a different directory >structure. That is because many hugin files use the form #include >"pano13/xxxx", and there is no such directory in the panotools tree. >The corresponding directory is called panotools/libpano. > >It would be better to use the panotools tree, as built, to build >hugin. The simplest way to achieve that would be to change the name >of panotools/libpano to panotools/pano13. You can rename the folder, or just check it out like this: svn co https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/libpano pano13 I'll update the instructions on the web-page. Though running `make install` should put all the files you need for linking in a 'pano13' folder somewhere. We could rename the folder in SVN to pano13, but this would only work because we don't have a src/ subdirectory. When I initially set all this up I neglected to put the code in src/ - We still have this unfortunate mess where all the files are in the root of the project. -- Bruno |
From: Thomas S. <tks...@gm...> - 2010-01-16 23:17:18
|
Hi Bruno I don't think we should rename anything in the panotools tree. I am satisfied with using INSTALL to create the directories hugin wants, and have committed both libpano and hugin build script updates for that. They work fine together on Windows and are not supposed to be visible on Linux or OSX. So if you get no build problems on Linux I would guess we can consider this problem resolved. I prefer this way because it decouples the hugin and panotools tree structures completely; their build systems share only the special panotools install directory, which no other package need ever see. BTW it is still necessary to download panotools starting at trunk/libpano if one is going to use the CMake script to build it in the hugin SDK. It would be nice to add a CMakeLists.txt in the trunk root that makes that unnecessary. Best, Tom On Sat, Jan 16, 2010 at 7:35 AM, Bruno Postle <br...@po...> wrote: > On Fri 15-Jan-2010 at 20:14 -0800, Tom Sharpless wrote: > > > >At present, to build hugin it is necessary to copy headers and > >libraries from the panotools build tree into a different directory > >structure. That is because many hugin files use the form #include > >"pano13/xxxx", and there is no such directory in the panotools tree. > >The corresponding directory is called panotools/libpano. > > > >It would be better to use the panotools tree, as built, to build > >hugin. The simplest way to achieve that would be to change the name > >of panotools/libpano to panotools/pano13. > > You can rename the folder, or just check it out like this: > > svn co > https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/libpanopano13 > > I'll update the instructions on the web-page. > > Though running `make install` should put all the files you need for > linking in a 'pano13' folder somewhere. > > We could rename the folder in SVN to pano13, but this would only > work because we don't have a src/ subdirectory. When I initially > set all this up I neglected to put the code in src/ - We still have > this unfortunate mess where all the files are in the root of the > project. > > -- > Bruno > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Thomas S. <tks...@gm...> - 2010-01-16 23:27:50
|
Hi All I should emphasize that I've made several correlated changes in panotools and hugin in the last couple days, so you must update & install libpano before building the current hugin. I don't plan any further changes in libpano, but am still debugging so might post some bugfixes. Regards, Tom On Sat, Jan 16, 2010 at 6:17 PM, Thomas Sharpless <tks...@gm...>wrote: > Hi Bruno > > I don't think we should rename anything in the panotools tree. I am > satisfied with using INSTALL to create the directories hugin wants, and have > committed both libpano and hugin build script updates for that. They work > fine together on Windows and are not supposed to be visible on Linux or OSX. > > So if you get no build problems on Linux I would guess we can consider this > problem resolved. > > I prefer this way because it decouples the hugin and panotools tree > structures completely; their build systems share only the special panotools > install directory, which no other package need ever see. > > BTW it is still necessary to download panotools starting at trunk/libpano > if one is going to use the CMake script to build it in the hugin SDK. It > would be > nice to add a CMakeLists.txt in the trunk root that makes that unnecessary. > > Best, Tom > > > > On Sat, Jan 16, 2010 at 7:35 AM, Bruno Postle <br...@po...> wrote: > >> On Fri 15-Jan-2010 at 20:14 -0800, Tom Sharpless wrote: >> > >> >At present, to build hugin it is necessary to copy headers and >> >libraries from the panotools build tree into a different directory >> >structure. That is because many hugin files use the form #include >> >"pano13/xxxx", and there is no such directory in the panotools tree. >> >The corresponding directory is called panotools/libpano. >> > >> >It would be better to use the panotools tree, as built, to build >> >hugin. The simplest way to achieve that would be to change the name >> >of panotools/libpano to panotools/pano13. >> >> You can rename the folder, or just check it out like this: >> >> svn co >> https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/libpanopano13 >> >> I'll update the instructions on the web-page. >> >> Though running `make install` should put all the files you need for >> linking in a 'pano13' folder somewhere. >> >> We could rename the folder in SVN to pano13, but this would only >> work because we don't have a src/ subdirectory. When I initially >> set all this up I neglected to put the code in src/ - We still have >> this unfortunate mess where all the files are in the root of the >> project. >> >> -- >> Bruno >> >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues >> through >> interactions with peers, luminaries and emerging and established >> companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> PanoTools-devel mailing list >> Pan...@li... >> https://lists.sourceforge.net/lists/listinfo/panotools-devel >> > > |
From: Bruno P. <br...@po...> - 2010-01-16 23:30:37
|
On Sat 16-Jan-2010 at 18:17 -0500, Tom Sharpless wrote: > > BTW it is still necessary to download panotools starting at > trunk/libpano if one is going to use the CMake script to build it > in the hugin SDK. It would be nice to add a CMakeLists.txt in the > trunk root that makes that unnecessary. The /svnroot/panotools/trunk/ folder isn't a 'trunk' in the same way as it is in Hugin. Each panotools/trunk/ sub-directory is a separate project where there is no reason you would want to build them at the same time. -- Bruno |