Hi, after I installed TortoiseSVN to edit translations directly, I thought it would be a nice idea to try building hugin myself. Though I am not a programmer. The explanation in the wiki is not bad, but even the very first step fails. Maybe someone can point me to where to read further instead of mentoring me click-by-click on this list.
System is WinXP SP3; unfortunately I installed Visual Studio in German, so I have to translate backwards here.
I created the directory D:\huginbase\enblend Cloned the repository, result D:\huginbase\enblend\enblend.
Now I opened enblend_msvc2003.sln. Changed the target configuration to 'release'. Compiled (I guess the 4th command from top in the build ("Erstellen") menu). I suppose I should get D:\huginbase\enblend\enblend\INSTALLDIR but I get nothing.
I guess some of the entries about missing files in the 2 build protocols contain the solution.
Could someone give me a hint? best regards Joachim
Kompilieren... cl : command line warning D9035 : The option "Wp64" is deprecated and will be removed in one of the next versions. tiff.cxx .\tiff.cxx(83) : fatal error C1083: File (Include) could not be opened: "tiff.h": No such file or directory png.cxx .\png.cxx(66) : fatal error C1083: File (Include) could not be opened: "png.h": No such file or directory jpeg.cxx .\jpeg.cxx(59) : fatal error C1083: File (Include) could not be opened: "jpeglib.h": No such file or directory exr.cxx .\exr.cxx(53) : fatal error C1083: File (Include) could not be opened: "ImfRgbaFile.h": No such file or directory
Kompilieren... cl : command line warning D9035 : The option "Wp64" is deprecated and will be removed in one of the next versions. getopt_long.c getopt.c Kompilieren... cl : command line warning D9035 : The option "Wp64" is deprecated and will be removed in one of the next versions. enblend.cc .\enblend.cc(74) : fatal error C1083: File (Include) could not be opened: "tiffconf.h": No such file or directory
J. Schneider wrote: > it would be a nice idea to try building hugin myself.
good idea! I'll be happy to mentor you. would it be OK for you, in exchange for the mentoring, to use your experience and improve the Wiki instructions?
> System is WinXP SP3; unfortunately I installed Visual Studio in German, > so I have to translate backwards here.
XP SP3, so you're on 32bit (there was never an SP3 for XP 64bit).
feel free to write the German output, ich verstehe. Will be easier for you, and we can translate the terms to English for the general public later on.
If it is OK for you, I suggest we do this mentoring session "live" on this mailing list, so others can profit too. But if you prefer not to expose the "dirty laundry" in public, i can contact you off-list. The important things are that 1. you have a good experience 2. we improve the Wiki for those stepping into the same process after you
> I created the directory D:\huginbase\enblend > Cloned the repository, result D:\huginbase\enblend\enblend.
this means that you installed all the tools, as well as Guido's SDK?
> Now I opened enblend_msvc2003.sln.
what version of Visual Studio do you have? the file to open is open huginbase/enblend/enblend_msvc2008.sln
the repository is currently in a broken state - a recent change breaks the MSVC (and the new CMake) build. Only autotools works.
the workaround is to step a little bit back in time, to before the state of the repository was broken. This is not too bad - the only things that have changed since are documentation stuff.
to step back in time, you need to look at the repository history, or log. You have a repository log locally; and there is the repository log of the master repository. They are not necessarily the same because you can do changes to your local repository without pushing them to the master one, although given that you are starting with this your repository is most likely an exact mirror of the master repository from which you synced.
the change that broke the build is the one saying "Couple the source code and the documentation more tightly".
what you need to do on your end is: right-click on the enblend folder and select "Hg pull" from the context menu. This will pull in the latest changes from the master repository. You want to look at the "hg log" (I think it is available in the TortoiseHg context menu, I don't have a Windows box in front of me right now and I am writing these instruction out of memory). Note down the revision number associated with the revision prior to the one saying "Couple the source code and the documentation more tightly". Do an "hg update" (again: available form the TortoiseHg context menu) to that revision number, with the clean option. This will bring your enblend tree back in time. Now you can continue with the build.
> Changed the target configuration to 'release'.
There should be multiple configurations. You want to avoid those with 'OpenMP' because to build with OpenMP you need the professional (paid) version of MSVC. If you have a good GPU, you may try to build the version with GPU. And if you often run out of disk space, build the version without ImageCache. Also if your CPU supports SSE2, build the version with SSE2. For example you can build "Release SSE2,GPU".
*but* before doing this, you need to complete the SDK. The current SDK lacks some of the dependencies to build enblend.
IIRC it is lcms that is missing (or outdated; 1.17 in the SDK and 1.18 referred to from the MSVC project files). * download the source from http://www.littlecms.com/lcms-1.18a.zip * unpack inside the SDK folder * inside lcms-1.18 there is a Projects folder. Select the MSVC2008 project. Start it. * in the configuration manager, select to build lcms only. You do not need the other tools (that will raise an error because they don't find some dependencies)
once you built lcms, continue with building enblend.
> I suppose I should get > D:\huginbase\enblend\enblend\INSTALLDIR but I get nothing.
IIRC it will be in "D:\huginbase\enblend\enblend\src\Release SSE2 GPU"
> I guess some of the entries about missing files in the 2 build protocols > contain the solution.
yes, the TIFF/JPEG/PNG libraries are inside wxWidgets. What version of wxWidgets do you have?
Hi,
I got the same problems as Joachim, including the German Visual C++
and the missing tiffconf.h.
If I´m understanding well what Yuv explained to us, it should be in
the wxWidgets directory ? I got wxWidgets 2.8.10 with the SDK and
Windows Search doesn´t find a tiff*.h in huginbase.
> J. Schneider wrote: >> it would be a nice idea to try building hugin myself.
> good idea! I'll be happy to mentor you. would it be OK for you, in > exchange for the mentoring, to use your experience and improve the Wiki > instructions?
> If it is OK for you, I suggest we do this mentoring session "live" on > this mailing list, so others can profit too.
That's fine for me.
>> I created the directory D:\huginbase\enblend >> Cloned the repository, result D:\huginbase\enblend\enblend.
> this means that you installed all the tools, as well as Guido's SDK?
I did. Just not wxWidgets that you mention later. Should this also be in the list of tools to install? I downloaded it and installed it to C:\Programme\wxWidgets-2.8.10.
>> Now I opened enblend_msvc2003.sln. > what version of Visual Studio do you have? the file to open is open > huginbase/enblend/enblend_msvc2008.sln
I have "Visual C++ 2008 Express Edition". I just didn't look closely enough. Now I took ...2008.sln. (But that doesn't change the result.) Strangely it cannot be opened by double clicking, but when dragged onto the MSVC window it works.
> the repository is currently in a broken state - a recent change breaks > the MSVC (and the new CMake) build. Only autotools works.
I don't know what autotools is, but I follow your steps to revert back to the unbroken stage.
> the workaround is to step a little bit back in time, > ... > This will bring your enblend tree back in time. Now you can > continue with the build.
Done. "Update to revision" is the command in my TortoiseHG installation. And 523 the rev. no.
>> Changed the target configuration to 'release'. > There should be multiple configurations. ...
> If you have a good GPU, you may try to build the
> version with GPU. And if you often run out of disk space, build the > version without ImageCache. Also if your CPU supports SSE2, build the > version with SSE2. For example you can build "Release SSE2,GPU".
The GPU option doesn't work with my Intel 945 Chipset but I needn't use it and I guess my Core2Duo T5500 (1.66GHz) supports SSE2, so "Release SSE2,GPU" is what I chose.
> *but* before doing this, you need to complete the SDK. The current SDK > lacks some of the dependencies to build enblend.
OK, this should be included in the wiki unless it is not fixed in the SDK.
> IIRC it is lcms that is missing (or outdated; 1.17 in the SDK and 1.18 > referred to from the MSVC project files).
Looks like missing. In D:\huginbase\enblend I don't find any lcms*.* file.
So I have D:\huginbase\enblend containing enblend\ ... No, I think first I throw all that stuff from D:\huginbase\enblend\enblend\*.* one level up and resync it to be sure. OK, now I have D:\huginbase\enblend\ with the enblend repository .hg in it and D:\huginbase\lcms-1.18\. Probably I should move it inside ...\enblend. -> D:\huginbase\enblend\lcms-1.18\.
> * inside lcms-1.18 there is a Projects folder. Select the MSVC2008 > project. Start it. > * in the configuration manager, select to build lcms only. You do not > need the other tools (that will raise an error because they don't find > some dependencies)
This results in D:\huginbase\enblend\lcms-1.18\Projects\VC2008\LibRelease\*obj and ...\vc90.idb and a log with 0 errors and 41 warnings like ..\..\src\cmsio1.c(964) : warning C4063: case "-1804014080" ist kein gültiger Wert für den Schalter der Enumeration "icTagTypeSignature". d:\huginbase\lcms-1.18\include\icc34.h(352): Siehe Deklaration von 'icTagTypeSignature'
> once you built lcms, continue with building enblend.
Do I understand correctly that MSVC should realize wxWidgets is installed and use the TIFF/JPEG/PNG libraries from there? Obviously not. MSVC still complains. If I understood the output
correctly I would probably be able to move my dirctoy wxWidgets-2.8.10 (now in C:\Programme\wxWidgets-2.8.10) in the right place. "..\..\..\wxW..." is counting from where? Tried moving it to D:\wxWidgets-2.8.10 and to D:\huginbase\enblend\wxWidgets-2.8.10 but this is not where it should be either.
>> I suppose I should get >> D:\huginbase\enblend\enblend\INSTALLDIR but I get nothing.
> IIRC it will be in "D:\huginbase\enblend\enblend\src\Release SSE2 GPU"
Yes, "D:\huginbase\enblend\src\Release (GPU, SSE2)" is the directory. So the one where the build log is put is also where the result should be. vc90.idb, vc90.pdb, filenameparse.obj is what I got apart from the log.
> HTH
Definitely! But you see you are dealing with a severe case of ignorance. Once you mastered bringing me to a working hugin build and we put that into the wiki more or less everybody should manage.
I'll be rebooting my workstation into Windows in a little while and will get back to both of you with more detailed feedback.
Yes, wxWidgets comes with the SDK. Downloading and installing the wxWidgets binaries is not the thing to do (Joachim) because there are some (small) [modifications] required to wxWidgets before building it.
These modifications are part of the instructions to build the SDK. You do not need to follow them. You do want to read them as they increase your awareness of what could be going wrong.
I suspect that the problem you are experiencing is because the MSVC projects in the enblend Hg repository is "out of sync" with the SDK - specifically it tries to look for a newer wxWidgets version than the one in the SDK. I'll confirm later (when my Windows system has booted up).
anbue wrote:
> Hi,
> I got the same problems as Joachim, including the German Visual C++
> and the missing tiffconf.h.
> If I´m understanding well what Yuv explained to us, it should be in
> the wxWidgets directory ? I got wxWidgets 2.8.10 with the SDK and
> Windows Search doesn´t find a tiff*.h in huginbase.
> Happy not to be alone.
> Andreas
>>> I guess some of the entries about missing files in the 2 build protocols
>>> contain the solution.
>> yes, the TIFF/JPEG/PNG libraries are inside wxWidgets. What version of
>> wxWidgets do you have?
J. Schneider wrote: > I downloaded it and installed it to C:\Programme\wxWidgets-2.8.10.
not good, please uninstall. the default binaries of wxWidgets are not ready for Hugin. They must be recompiled. And Hugin and Enblend expect them at a different location than where the binaries install.
You should have wxWidgets-2.8.10 inside the SDK. If you don't let me know and I'll guide you through the process of updating your SDK with wxWidgets-2.8.10
> Done. "Update to revision" is the command in my TortoiseHG installation. > And 523 the rev. no.
good. well done.
> The GPU option doesn't work with my Intel 945 Chipset but I needn't use > it and I guess my Core2Duo T5500 (1.66GHz) supports SSE2, so "Release > SSE2,GPU" is what I chose.
SSE2,GPU will not work with your chipset. Go simple Release for now.
> So I have D:\huginbase\enblend containing enblend\ ... > No, I think first I throw all that stuff from > D:\huginbase\enblend\enblend\*.* one level up and resync it to be sure.
yes, you want enblend's source code to be at the first level under D:\huginbase
> OK, now I have D:\huginbase\enblend\ with the enblend repository .hg
good
> D:\huginbase\lcms-1.18\. Probably I should move it inside ...\enblend. > -> D:\huginbase\enblend\lcms-1.18\.
no. you want to leave it D:\huginbase\lcms-1.18\ - in general you don't want to move stuff around that came with the SDK. The only locations we need to fix are those of the folders that you are adding inside D:\huginbase.
>> * inside lcms-1.18 there is a Projects folder. Select the MSVC2008 >> project. Start it. >> * in the configuration manager, select to build lcms only. You do not >> need the other tools (that will raise an error because they don't find >> some dependencies) > This results in > D:\huginbase\enblend\lcms-1.18\Projects\VC2008\LibRelease\*obj and > ...\vc90.idb > and a log with 0 errors and 41 warnings like > ..\..\src\cmsio1.c(964) : warning C4063: case "-1804014080" ist kein > gültiger Wert für den Schalter der Enumeration "icTagTypeSignature". > d:\huginbase\lcms-1.18\include\icc34.h(352): Siehe Deklaration > von 'icTagTypeSignature'
good. now rinse and repeat with lcms-1.18 at the right location ;-)
>> once you built lcms, continue with building enblend. > Do I understand correctly that MSVC should realize wxWidgets is > installed and use the TIFF/JPEG/PNG libraries from there?
maybe. it is a combination of factors.
> I would probably be able to move my dirctoy wxWidgets-2.8.10 > (now in C:\Programme\wxWidgets-2.8.10) in the right place. > "..\..\..\wxW..." is counting from where? > Tried moving it to D:\wxWidgets-2.8.10 and to > D:\huginbase\enblend\wxWidgets-2.8.10 > but this is not where it should be either.
no. please don't move around SDK folders. we will fix what is in your folders relatively to them.
>> HTH > Definitely! > But you see you are dealing with a severe case of ignorance. Once you > mastered bringing me to a working hugin build and we put that into the > wiki more or less everybody should manage.
ignorance can be easily fixed. I'm an ignorant myself. I think the last all scient human being died two or three centuries ago. Since then, we're all ignorants one way or another, simply because the whole body of human knowledge would take much much more than a life time to learn/understand.
I think I am dealing with a normal case of open source itch; and with a severe case of impatience coupled with a healthy dose of curiosity; ability to fiddle; willingness to take risks. A good cocktail :-)
The medicine is simple: stop. breath. think. There is time to act later.
Now here is what I want you to do:
* right-click on enblend in the property manager (on the left hand side of the IDE). Look at its properties.
* Navigate on the left hand side to Configuration Properties -> C/C++ -> General
* On the right and side there is an Additional Include Directories property.
* Click on it, then click on the ... button on its right to edit it. Do not edit (unless you know what you are doing), just read the values that are there and post them here.
* These values are folders. You want to check that these folders exist, relative to enblend\src
* You already have most of them from the SDK, I suspect one or two may be missing. Which ones?
* Repeat the same exercise with Configuration Properties -> Linker -> General and the Additional Library Directories property.
you are much closer to success than you think; but you are also very excited and willing to try things that may break your builds. Don't worry, keep playing, the worse case scenario is that you'll have to unpack a fresh SDK; and sync a fresh enblend checkout; and follow the instruction from the beginning again.
>> I downloaded it and installed it to C:\Programme\wxWidgets-2.8.10. > not good, please uninstall.
Done.
> the default binaries of wxWidgets are not > ready for Hugin. They must be recompiled. And Hugin and Enblend expect > them at a different location than where the binaries install.
OK, I'm going to get myself the source.
> You should have wxWidgets-2.8.10 inside the SDK. If you don't let me > know and I'll guide you through the process of updating your SDK with > wxWidgets-2.8.10
I guess we'll have to do this. I looked for tiff.h and wx*.* inside huginbase and there is nothing.
Probably we should structure the instructions on the wiki like "Ideally you get these tools and start compiling ... (whole process) and in case dependency 1/2/... is missing/broken get it here/here/... (describing these additional processes in later sections or on separate pages)." But we can think about this later.
>> -> D:\huginbase\enblend\lcms-1.18\. > no. you want to leave it D:\huginbase\lcms-1.18\
Done.
>>> * inside lcms-1.18 there is a Projects folder. Select the MSVC2008 >>> project. Start it. >>> * in the configuration manager, select to build lcms only. You do not >>> need the other tools (that will raise an error because they don't find >>> some dependencies) >> This results in >> D:\huginbase\enblend\lcms-1.18\Projects\VC2008\LibRelease\*obj and >> ...\vc90.idb >> and a log with 0 errors and 41 warnings like >> ..\..\src\cmsio1.c(964) : warning C4063: case "-1804014080" ist kein >> gültiger Wert für den Schalter der Enumeration "icTagTypeSignature". >> d:\huginbase\lcms-1.18\include\icc34.h(352): Siehe Deklaration >> von 'icTagTypeSignature'
> good. now rinse and repeat with lcms-1.18 at the right location ;-)
Done. (I'm feeling so fresh and clean now ;-) Still same warnings, but no errors. I leave the result where it is.
>>> once you built lcms, continue with building enblend. >> <snip> [Tried to move my directoy wxWidgets-2.8.10 to a place >> where MSVC finds it to compile enblend] > no. please don't move around SDK folders. we will fix what is in your > folders relatively to them.
OK. But for now I uninstalled it anyway and I am going to compile it according to your instructions.
> * right-click on enblend in the property manager (on the left hand side > of the IDE). Look at its properties.
> * Navigate on the left hand side to Configuration Properties -> C/C++ -> > General
> * On the right and side there is an Additional Include Directories property.
> * Click on it, then click on the ... button on its right to edit it. Do > not edit (unless you know what you are doing), just read the values that > are there and post them here.
> * These values are folders. You want to check that these folders exist, > relative to enblend\src
So ..\.. is huginbase and e.g. ..\..\STLport-trunk\stlport would be huginbase\STLport-trunk\stlport. OK
> * You already have most of them from the SDK, I suspect one or two may > be missing. Which ones?
..\..\STLport-trunk\stlport NO ..\include YES ..\..\include NO ..\..\tiff-3.8.2\libtiff NO ..\..\wxWidgets-2.8.10\src\jpeg all wxWidgets are missing but you are ..\..\wxWidgets-2.8.10\src\png going to tell me what to do about ..\..\wxWidgets-2.8.10\src\zlib this. ..\..\boost_1_39_0 NO ..\..\lcms-1.18\include YES ..\..\libxmi-1.2 NO . of course ..\..\glew\include NO ..\..\glut\include NO
> * Repeat the same exercise with Configuration Properties -> Linker -> > General and the Additional Library Directories property.
..\..\wxWidgets-2.8.10\lib\vc_lib NO, see above ..\..\lcms-1.18\Lib\MS YES ..\..\libxmi-1.2\Release NO ..\..\STLport-trunk\lib NO ..\..\Deploy\lib\Release NO ..\..\tiff-3.8.2\libtiff NO ..\..\glew\lib NO ..\..\glut\Release NO
Quite a few missing. Do I really need all of them?
> you are much closer to success than you think; but you are also very > excited and willing to try things that may break your builds. Don't > worry, keep playing, the worse case scenario is that you'll have to > unpack a fresh SDK; and sync a fresh enblend checkout; and follow the > instruction from the beginning again.
J. Schneider wrote: >> the default binaries of wxWidgets are not >> ready for Hugin. They must be recompiled. And Hugin and Enblend expect >> them at a different location than where the binaries install. > OK, I'm going to get myself the source.
before doing that we should try to make the wxWidgets that are inside the SDK work. This way we'll know if the SDK needs updating.
I'm looking at the SDK (20090509, from Guido) right now, and I see the following folders:
* wxWidgets-2.9.10 * UnxUtils * OpenEXR * libxml2-2.7.3 * libpano (you'll replace this one *later* - first let's get Hugin working as-is) * glew * gettext * expat-2.0.1 * exiv2-0.18.1 * exiftool * Deploy * boost_1_39_0 * autopano-sift-C
>> You should have wxWidgets-2.8.10 inside the SDK. If you don't let me >> know and I'll guide you through the process of updating your SDK with >> wxWidgets-2.8.10 > I guess we'll have to do this. I looked for tiff.h and wx*.* inside > huginbase and there is nothing.
you might be better off starting with a new, clean huginbase. but wait, there is something you can do before.
> Probably we should structure the instructions on the wiki like > "Ideally you get these tools and start compiling ... (whole process) > and in case dependency 1/2/... is missing/broken get it here/here/... > (describing these additional processes in later sections or on separate > pages)." But we can think about this later.
Yes. Hugin and many of the dependencies are a moving target, so there will be often missing/broken stuff. In general it should be: try with the SDK, and if it does not work, start updating the SDK.
There are already instructions on the wiki to build the SDK.
>>> -> D:\huginbase\enblend\lcms-1.18\. >> no. you want to leave it D:\huginbase\lcms-1.18\ > Done.
before starting from scratch you may want to zip lcms-1.18 and save it away. this will be an upgrade to a freshly installed SDK (huginbase).
We had already discussed this kind of incremental upgrade with Guido. The instructions, and what you are building now, could be a step further in the implementation.
So the instructions should be something like: - if enblend does not find lcms.h, look at the project properties to identify what folder it should be in. and if your don't have that folder, or if you have e.g. lcms-0.17 while enblend require lcms-0.18, download the lcms-0.18 replacement (incremental update to the SDK). and only if there is no download (or if you are feeling an itch), go with the build instructions, which should be on the wiki page describing how to build the SDK.
>> * You already have most of them from the SDK, I suspect one or two may >> be missing. Which ones?
> Quite a few missing. Do I really need all of them?
yes you do. and you bumped into a problem that I hope will be solved (at least partially) with the next edition of the SDK. The current Hugin SDK has only what it takes to *build* Hugin. Not the related tools, like Enblend. We will change that.
First, I see from your report that your copy of the SDK is incomplete.
the instructions to build it are in the INSTALL file, and make use of nmake (that you have installed with MSVC).
> ..\include YES > ..\..\include NO
I would not worry about this one for now - IIRC it will be generated when you build enblend/enfuse
> ..\..\tiff-3.8.2\libtiff NO
ah yes, so it does not even look inside wxWidgets for tiff. you could try to replace it with ..\..\wxWidgets-2.8.10\src\tiff - this would solve us one extra folder. Else, we'll have to build tiff-3.8.2.
> ..\..\wxWidgets-2.8.10\src\jpeg all wxWidgets are missing but you are > ..\..\wxWidgets-2.8.10\src\png going to tell me what to do about > ..\..\wxWidgets-2.8.10\src\zlib this. > ..\..\boost_1_39_0 NO
> . of course > ..\..\glew\include NO
mhhh. something is definitely broken with the unpacked SDK. When you unpack an SDK from the start, do you find these folders?
> ..\..\lcms-1.18\include YES
you built it :)
> ..\..\libxmi-1.2 NO
this is also Enblend-only and thus not in the current SDK.
there is a libxmi.sln inside it, IIRC you just need to start it. Ask if you have questions.
> ..\..\glut\include NO
http://www.xmission.com/~nate/glut.html - I am not sure if just unpacking the bin.zip file inside huginbase will be enough. try that. if it does not work, get src.zip, there are instructions inside. if you need help, ask.
>> * Repeat the same exercise with Configuration Properties -> Linker -> >> General and the Additional Library Directories property.
> ..\..\wxWidgets-2.8.10\lib\vc_lib NO, see above > ..\..\lcms-1.18\Lib\MS YES > ..\..\libxmi-1.2\Release NO > ..\..\STLport-trunk\lib NO > ..\..\Deploy\lib\Release NO > ..\..\tiff-3.8.2\libtiff NO > ..\..\glew\lib NO > ..\..\glut\Release NO
all of these will be solved when you dowloaded / installed / built the above - always inside huginbase.
real life interfered a bit in the meantime but now I am back. And next weekend I'm going to help my sister move all across Germany and won't be at home much, but anyway, step by step ...
> I'm looking at the SDK (20090509, from Guido) right now, and I see the > following folders:
I don't know what I did to my SDK before but after downloading anew it looks like this (right column is mine):
> * wxWidgets-2.9.10 wxWidgets-2.8.10 > * UnxUtils OK > * OpenEXR OK > * libxml2-2.7.3 OK > * libpano (you'll replace ... OK > * glew OK > * gettext OK > * expat-2.0.1 OK > * exiv2-0.18.1 OK > * exiftool OK > * Deploy OK > * boost_1_39_0 OK > * autopano-sift-C OK
So the only difference is the wxWidgets version. Don't ask me why it wasn't there before.
So before checking all the dependencies again I just tried compiling enblend again. Now the errors are: For vigra_impex: 1>.\tiff.cxx(83) : fatal error C1083: Datei (Include) kann nicht geöffnet werden: "tiff.h": No such file or directory
I have already chnged that one dependeny to ..\..\wxWidgets-2.8.10\src\tiff as you suggest below. Somehow it is still not found.
for enblend: 2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C2018: Unbekanntes Zeichen '0x40' 2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C2018: Unbekanntes Zeichen '0x40' 2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'icUInt8Number' 2>d:\huginbase\lcms-1.18\include\icc34.h(154) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt. and the same forth and forth.
--
So now I recheck the dependencies and there is a bit more present:
..\..\STLport-trunk\stlport NO ..\include YES ..\..\include NO ..\..\tiff-3.8.2\libtiff NO but now changed to ..\..\wxWidgets-2.8.10\src\jpeg ..\..\wxWidgets-2.8.10\src\jpeg now YES ..\..\wxWidgets-2.8.10\src\png now YES ..\..\wxWidgets-2.8.10\src\zlib now YES ..\..\boost_1_39_0 now YES ..\..\lcms-1.18\include YES ..\..\libxmi-1.2 NO . of course ..\..\glew\include now YES ..\..\glut\include NO
>> * Repeat the same exercise with Configuration Properties -> Linker -> >> General and the Additional Library Directories property.
..\..\wxWidgets-2.8.10\lib\vc_lib now YES ..\..\lcms-1.18\Lib\MS YES ..\..\libxmi-1.2\Release NO ..\..\STLport-trunk\lib NO ..\..\Deploy\lib\Release now YES ..\..\tiff-3.8.2\libtiff NO ..\..\glew\lib now YES ..\..\glut\Release NO
So now I go on getting what is missing as you describe. I'll begin them all and will see for each one where I get stuck.
OK. Rev 6512. I have got STLport now in my huginbase. Is it later to be renamed STLport-trunk?
> the instructions to build it are in the INSTALL file, and make use of > nmake (that you have installed with MSVC).
What I read on the wiki page mentioned above seems to be the same in short. Am I going to build the STLport iostreams library? Anyway on the MSVC command line I get: setenv: The command was either misspelled or couldn't be found. Looks like I started somehow completely wrong.
> there is a libxmi.sln inside it, IIRC you just need to start it.
No. But the wiki says, I have to apply the libxmi-1.2.diff patch. Where do I get it and how to apply a patch?
--
3. glut
>> ..\..\glut\include NO
> http://www.xmission.com/~nate/glut.html - I am not sure if just > unpacking the bin.zip file inside huginbase will be enough. try that. if > it does not work, get src.zip, there are instructions inside.
Got the bin.zip (glut-3.7.6-bin.zip) and extracted to huginbase\glut-3.7.6-bin. We'll see later if it works.
--
So far so good. If you understand German: Mühsam ernährt sich das Eichhörnchen!" is what we say about such proceeding. Anyway, step by step ...
Looking forward to more instructions and more spare time Joachim
J. Schneider wrote: > real life interfered a bit in the meantime but now I am back. And next > weekend I'm going to help my sister move all across Germany and won't be > at home much, but anyway, step by step ...
I hope the move went well and you did not have the same weather we're having here (pouring rain, and cold wind).
>> * wxWidgets-2.9.10 wxWidgets-2.8.10
...
> So the only difference is the wxWidgets version. Don't ask me why it > wasn't there before.
I think this was a typo of mine. It is 2.8.10 here too. That said, wxWidgets evolves steadily and improves the user interface to Hugin, so it is good to know / document how to build the latest stable version, which currently is 2.9.0, released 2009-09-08. Info on releases at http://www.wxwidgets.org/ and http://trac.wxwidgets.org/wiki/Roadmap
...
> ..\..\include NO
if I am not mistaken we can ignore this one.
> ..\..\tiff-3.8.2\libtiff NO but now changed to > ..\..\wxWidgets-2.8.10\src\jpeg
I don't think it will work, and anyway it is not a good thing to do. libtiff inside wxWidget is 3.6.1, very old. 3.8.2 was the current stable version in 2007 IIRC. In the meantime it's 3.9.1 and they are already releasing 4.0.0 beta.
There is a libtiff-3.8.2 in my SDK folder. I don't recall its origin, but I have built 3.9.1 and replaced it successfully:
* start a MSVC shell * execute the following commands VCVARSALL * cd into the tiff folder * execute the following commands nmake /f makefile.vc clean nmake /f makefile.vc
It will fail (while building some tools), but all we need is the library and it is produced before.
If you are using anything else but tiff-3.8.2, remember to adjust the project properties (C/C++ and Linker for each target) in MSVC before launching the build.
One thing I saw different in 3.9.1 from 3.8.2 is support for JBIG-KIT, a lossless type of compression. It seems to be patent-encumbered until February 2011, so I did not investigate further its use (but may be interesting later on)
> ..\..\lcms-1.18\include YES
did you document the instructions for this in the wiki (do you edit as you go along) ?
>> the instructions to build it are in the INSTALL file, and make use of >> nmake (that you have installed with MSVC). > What I read on the wiki page mentioned above seems to be the same in > short. Am I going to build the STLport iostreams library?
Is that what is said in stloport-trunk\INSTALL ?
> Anyway on the MSVC command line I get: > setenv: The command was either misspelled or couldn't be found. > Looks like I started somehow completely wrong.
where in the instructions did you find "setenv" ? have you followed the instructions in stlport-trunk\INSTALL ?
>> there is a libxmi.sln inside it, IIRC you just need to start it. > No. But the wiki says, I have to apply the libxmi-1.2.diff patch. > Where do I get it and how to apply a patch?
I think the patch is for 64bit. you don't need to patch for your 32bit Windows XP. is there no libxmi.sln inside?
> 3. glut >>> ..\..\glut\include NO >> http://www.xmission.com/~nate/glut.html - I am not sure if just >> unpacking the bin.zip file inside huginbase will be enough. try that. if >> it does not work, get src.zip, there are instructions inside. > Got the bin.zip (glut-3.7.6-bin.zip) and extracted to > huginbase\glut-3.7.6-bin. We'll see later if it works.
I am starting to lose track of things. Maybe time for an initial summary of the steps, starting from the SDK?
> I hope the move went well and you did not have the same weather we're > having here (pouring rain, and cold wind).
Only on the road, so all went well.
First something you mentioned at the end of your mail: > I am starting to lose track of things. Maybe time for an initial > summary of the steps, starting from the SDK? Well, if even you lose track ... I had that same feeling as well.
> did you document the instructions for this in the wiki (do you edit as > you go along) ? To be honest, at the moment I feel it is a little too much trial and error to document it "live" in the wiki. But I did this locally to keep track of all the ramifications. Without having a real overview of what I am doing this is really difficult. I wrote it down and uploaded it to http://www.joachimschneider.info/moving_target.html As you see, I always have to remind myself what it is that I am building, e.g. now it is a dependency of enblend (and not directly of hugin).
Now I go on and secondly, I would like to solve one misunderstanding.
>> ..\..\tiff-3.8.2\libtiff NO but now changed to >> ..\..\wxWidgets-2.8.10\src\jpeg
Looks like I didn't read something correctly, took a wrong line or something like this. So how was it before? I re-entered a line ..\..\tiff-3.8.2\libtiff for the moment (though I might change it later) and left ..\..\wxWidgets-2.8.10\src\jpeg in the list. So the list now begins with ..\..\STLport-trunk\stlport ..\include ..\..\include ..\..\tiff-3.8.2\libtiff ..\..\wxWidgets-2.8.10\src\tiff ..\..\wxWidgets-2.8.10\src\jpeg and ... png, zlib,
I guess I fixed this. (But just to understand it better: If tiff.h is what is needed and it is in the mentioned wxWidgests folder, then changing the entry to that folder should generally work?)
>>> the instructions to build it are in the INSTALL file, and make use of >>> nmake (that you have installed with MSVC). >> What I read on the wiki page mentioned above seems to be the same in >> short. Am I going to build the STLport iostreams library?
> Is that what is said in stloport-trunk\INSTALL ?
There are instructions on "Unpacking and installing STLport" and then they say "If you DO NOT plan to use STLport iostreams and/or locale implementation but just the STL, you do not have to build the library." The separate instuctions to build this follow. Now I understand that this is the actual build process and the first steps are just preliminary actions. So building the library is not an option in a two-part-process but it is the main thing. And I go on.
>> Anyway on the MSVC command line I get: >> setenv: The command was either misspelled or couldn't be found. >> Looks like I started somehow completely wrong.
> where in the instructions did you find "setenv" ? have you followed the > instructions in stlport-trunk\INSTALL ?
No, this was from the wiki. I was confuse by two instructions.
And after I changed into the STLport directory even configure --help yields a result - I didn't understand that this command is is not part of MSVC. OK, so configure msvc9 gives output that looks OK, though doc\README.msvc says it is configure -c msvcX (where X is the version), but the document is for an older version (2005). Same with the instruction in readme.windows: If I omit the "-c" it states that the desired compiler has been chosen, but "Das Sprungziel - opt_xtra wurde nicht gefunden." seems to mean that it did not understand --extra-cxxflag "/D_WIN32_WINNT=0x0501" in configure msvc9 --extra-cxxflag "/D_WIN32_WINNT=0x0501" But the instructions suggest that they are most important for older versions of windows and since I use XP for building STLport and the same OS for using STLport for building other software this seems to be OK. So I leave it at configure msvc9 and continue with the README.msvc instructions: "cd "C:\Program Files\Microsoft Visual Studio\VC98\Bin"" seems to be "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin" in my case.
The problem with the next step cd C:\STLport\build\lib (d:\huginbase\STLport\build\lib) and nmake /fmsvc.mak install is that my \build\lib folder is empty. No msvc.mak inside. (Though several instances in other subdirectories.)
better late than never. Rename folder to STLport, start over, just that the readme.msvc is not contained in this version, which I guess I should still follow. So I have to get myself the svn version again to read it alongside. Anyway: Runs without error message in the end. (Can't find a build log that would tell me if anything occurred in between, but I guess it would have told in the end.) Hurray!
>>> there is a libxmi.sln inside it, IIRC you just need to start it. >> No. But the wiki says, I have to apply the libxmi-1.2.diff patch. >> Where do I get it and how to apply a patch?
> I think the patch is for 64bit. you don't need to patch for your 32bit > Windows XP. is there no libxmi.sln inside?
No, there's no *.sln inside. In the INSTALL file it says 1. Do `./configure', `make', and `make install', as usual. This will install both libxmi and its header file, xmi.h. but I'm not sure if "installing" is what I want to do in this case.
> First something you mentioned at the end of your mail: > > I am starting to lose track of things. Maybe time for an initial > > summary of the steps, starting from the SDK? > Well, if even you lose track ... > I had that same feeling as well.
> > did you document the instructions for this in the wiki (do you edit as > > you go along) ? > To be honest, at the moment I feel it is a little too much trial and > error to document it "live" in the wiki. But I did this locally to > keep track of all the ramifications. Without having a real overview of > what I am doing this is really difficult. > I wrote it down and uploaded it to > http://www.joachimschneider.info/moving_target.html > As you see, I always have to remind myself what it is that I am > building, e.g. now it is a dependency of enblend (and not directly of > hugin).
> I'd like to set up a Windows hugin development environment, but the > terrifying length of this thread is somewhat deterrent.
> Do you recon your moving target is closing in?
Well, I don't have the slightest clue. Any step in one of the "branches" can yield more steps. Or end and lead back to "trunk", i.e. the main objective to build hugin. But if you just follow the actual steps (http://www.joachimschneider.info/moving_target.html) and leave out all my errors, mistakes and misapprehensions it is not so much you actually have to do (to reach whatever intermediate result it is that I have got).
J. Schneider wrote: > Oskar Sander schrieb: >> I'd like to set up a Windows hugin development environment, but the >> terrifying length of this thread is somewhat deterrent.
>> Do you recon your moving target is closing in? > Well, I don't have the slightest clue. Any step in one of the "branches" > can yield more steps. Or end and lead back to "trunk", i.e. the main > objective to build hugin. But if you just follow the actual steps > (http://www.joachimschneider.info/moving_target.html) and leave out all > my errors, mistakes and misapprehensions it is not so much you actually > have to do (to reach whatever intermediate result it is that I have got).
exactly! Actually you're very close. I could just limit you in your creativity and curiosity and tell you to do A/B/C and that's it. But this would not help you nor me. Part of the mentoring job is to deal with things that I took for granted and look at them anew. Another part of it is to help you develop that perspective on your own terms. Following instructions blindly will inevitably break at the code, the dependencies, or both. Understanding the interaction (which is what you are doing now) is key to being able to understand what went wrong and fix it. First fix small things (you already have the tools, you know how to manipulate project properties in MSVC); then larger things (such as finding either binaries or source code packages of the dependencies and integrating them into your build process).
In terms of "just following instructions" (Oskar's question) Windows is not the easiest platform. You can speed through the Ubuntu instructions on the wiki and be up and running in less than an hour, and given its statistics and the feedback we get from it I guess that hundreds if not thousands of people have done it.
Most people will stop there. It works for them, fine. It does not, they will look for alternatives but won't have the courage to admit it. Some actually come here on the list and make us aware of the changes that broke the instructions. Few make the step to really understand what's going on. Some make the step to update / edit the wiki. The more dangerous are those that make the step to edit the wiki (or to suggest changes) without understanding them. But we keep those at bay (I am known to bark and sometimes I even bite ;-) ). The best ones are those like Joachim, who are driven by curiosity and will peek and poke fiddling at things until they get them working.
I actually fear the day when the Windows (or OSX) build will be documented as well as the Ubuntu one. There is so much that can go wrong in Windows; and then people take things for granted and when they don't work as expected it is Hugin's fault.
Your documentation is excellent, Joachim. It's a good summary of what you did. At some point you'll need to split it into different levels: which one is an update of the SDK (e.g. tiff-3.8.2) and which are part of building with an existing SDK; and how to find out what makes a build with the existing SDK fail, and how to fix those failures.
You're on the good road and in the right direction.
I'm not sure yet how much time I can dedicate to this in the coming week, but our common journey is on my todo list, so you'll hear from me.
> I guess I fixed this. (But just to understand it better: If tiff.h is > what is needed and it is in the mentioned wxWidgests folder, then > changing the entry to that folder should generally work?)
a .h file is a header file. you also need either the associated source code (.c or .cpp) or the associated binary object file (.o) - I might be wrong on the detail - before hacking into Hugin I only did a little bit of C twenty years ago, so the concepts are pretty rusty in my head. Others may explain things better.
> What is it that I need? The newly created stuff inside libtiff? There is > a new libtiff.dll compiled.
.dll are for dynamic linking. we link statically, so what we need is .lib
> So I get myself version 5.2.1 as you recommended >> I see that STLport released 5.2.1 recently >> http://sourceforge.net/projects/stlport/files/ > better late than never. > Rename folder to STLport, start over, just that the readme.msvc is not > contained in this version, which I guess I should still follow. So I > have to get myself the svn version again to read it alongside. > Anyway: Runs without error message in the end. (Can't find a build log > that would tell me if anything occurred in between, but I guess it would > have told in the end.) > Hurray!
so you built STLport successfully? well done! It is better not to rename it, but to change the project properties. Renaming makes it more difficult to keep track of the version.
>>> 2. libxmi-1.2 > In the INSTALL file it says > 1. Do `./configure', `make', and `make install', as usual. This will > install both libxmi and its header file, xmi.h. > but I'm not sure if "installing" is what I want to do in this case.
these are standard instruction for Linux/Unix. They don't work for MSVC. Also IIRC you just want to unpack it there, not necessarily build/install it. But I may be wrong. I'm currently on Linux and it's late. I shall look at my Windows box soon.
Hallo Yuv, hope the surprise back home was not too bad.
>> I guess I fixed this. (But just to understand it better: If tiff.h is >> what is needed and it is in the mentioned wxWidgests folder, then >> changing the entry to that folder should generally work?)
> a .h file is a header file. you also need either the associated source > code (.c or .cpp) or the associated binary object file (.o) - I might be > wrong on the detail - ...
I was asking just because tiff.h was the file the compiler complained about it were missing. Anyway there are heaps of .obj and .c files in tiff-3.9.1\libtiff but no tiff.obj or tiff.c. Maybe we'll see later what MSVC will complain about.
>> What is it that I need? The newly created stuff inside libtiff? There is >> a new libtiff.dll compiled.
the process is so new to me that I don't know what to expect as the result of a build, if not simply an .exe.
> .dll are for dynamic linking. we link statically, so what we need is .lib
present as well.
>> So I get myself version 5.2.1 as you recommended >>> I see that STLport released 5.2.1 recently >>> http://sourceforge.net/projects/stlport/files/ >> better late than never. >> Rename folder to STLport, start over, just that the readme.msvc is not >> contained in this version, which I guess I should still follow. So I >> have to get myself the svn version again to read it alongside. >> Anyway: Runs without error message in the end. (Can't find a build log >> that would tell me if anything occurred in between, but I guess it would >> have told in the end.) >> Hurray!
> so you built STLport successfully? well done! It is better not to rename > it, but to change the project properties. Renaming makes it more > difficult to keep track of the version.
Logical. I tried to find why I did this and I think I misunderstood in INSTALL: "Make sure you do not rename this "stlport" subdirectory - that may result in compilation errors." But the SUBdirectory stlport is meant. But now I rename it back to STLport-5.2.1 that it probably was before. Changed the two occurrences in the project properties. Corrected in moving_target.html
>>>> 2. libxmi-1.2 >> In the INSTALL file it says >> 1. Do `./configure', `make', and `make install', as usual. This will >> install both libxmi and its header file, xmi.h. >> but I'm not sure if "installing" is what I want to do in this case.
> these are standard instruction for Linux/Unix. They don't work for MSVC. > Also IIRC you just want to unpack it there, not necessarily > build/install it. But I may be wrong. I'm currently on Linux and it's > late. I shall look at my Windows box soon.
OK, let's keep this one for later. Best regards Joachim
I just spend a little more time on the setup. Didn't get enblend to build
yet, but getting closer. I update the wiki with what I did in case somebody
tries to setup.
As I was reading this thread for a few walls I've been hitting... I saw that
one of my assumptions was probably wrong. I switched all the links
to libtiff to use wxtiff.lib instead... but seeing part of the thread makes
me question this... I'll get the other stuff, but why use png and jpg from
one lib, and tiff from another?
On Tue, Oct 20, 2009 at 3:31 PM, J. Schneider <j-schn...@gmx.de> wrote:
> Hallo Yuv,
> hope the surprise back home was not too bad.
> >> I guess I fixed this. (But just to understand it better: If tiff.h is
> >> what is needed and it is in the mentioned wxWidgests folder, then
> >> changing the entry to that folder should generally work?)
> > a .h file is a header file. you also need either the associated source
> > code (.c or .cpp) or the associated binary object file (.o) - I might be
> > wrong on the detail - ...
> I was asking just because tiff.h was the file the compiler complained
> about it were missing.
> Anyway there are heaps of .obj and .c files in tiff-3.9.1\libtiff but no
> tiff.obj or tiff.c.
> Maybe we'll see later what MSVC will complain about.
> >> What is it that I need? The newly created stuff inside libtiff? There is
> >> a new libtiff.dll compiled.
> the process is so new to me that I don't know what to expect as the
> result of a build, if not simply an .exe.
> > .dll are for dynamic linking. we link statically, so what we need is .lib
> present as well.
> >> So I get myself version 5.2.1 as you recommended
> >>> I see that STLport released 5.2.1 recently
> >>> http://sourceforge.net/projects/stlport/files/ > >> better late than never.
> >> Rename folder to STLport, start over, just that the readme.msvc is not
> >> contained in this version, which I guess I should still follow. So I
> >> have to get myself the svn version again to read it alongside.
> >> Anyway: Runs without error message in the end. (Can't find a build log
> >> that would tell me if anything occurred in between, but I guess it would
> >> have told in the end.)
> >> Hurray!
> > so you built STLport successfully? well done! It is better not to rename
> > it, but to change the project properties. Renaming makes it more
> > difficult to keep track of the version.
> Logical. I tried to find why I did this and I think I misunderstood in
> INSTALL: "Make sure you do not rename this "stlport" subdirectory - that
> may result in compilation errors." But the SUBdirectory stlport is meant.
> But now I rename it back to STLport-5.2.1 that it probably was before.
> Changed the two occurrences in the project properties. Corrected in
> moving_target.html
> >>>> 2. libxmi-1.2
> >> In the INSTALL file it says
> >> 1. Do `./configure', `make', and `make install', as usual. This will
> >> install both libxmi and its header file, xmi.h.
> >> but I'm not sure if "installing" is what I want to do in this case.
> > these are standard instruction for Linux/Unix. They don't work for MSVC.
> > Also IIRC you just want to unpack it there, not necessarily
> > build/install it. But I may be wrong. I'm currently on Linux and it's
> > late. I shall look at my Windows box soon.
> OK, let's keep this one for later.
> Best regards
> Joachim
> why use png and jpg from one lib, and tiff from another?
lazyness? you probably could also use tiff from wxWidget, but it is an older version. IIRC tifflib has added features that are worth the effort compared to what is in wxWidgets (and does not get updated frequently). I don't recall what it was. Mabye larger file size?
I think it would make sense to use png and jpg directly rather than through wxWidgets, but first you want to get Enblend up and running with the current setting.
Yuv schrieb: > Did I answer your questions? The question about libxmi? no, not yet. So far I did just what I wrote in moving_target: I unzipped it inside huginbase.
> I see at the end of moving_target.html something about copying enblend > and enfuse. Does this mean that you built them successfully?
No, this was only the instruction (yours or the wiki's) what to do after building. When I compiled all information about the process I had I also included steps that I hadn't executed yet myself. I think I have put everything so far into moving_target, I think it is up to date (just fixed a typo in the libxmi section).
After I had some hardware trouble I think I'm back now. (I'm just verifying that the machine runs reliably even under heavy load by processing a 60000px wide pano and mailing and browsing at the same time. Couldn't drive it into blue screen so far.)
I took my moving_target.html and my huginbase directory to reconsider where I was standing.
- trying to build enblend
- lcms built successfully
- wxWidgets found again after it looked like missing
- libtiff built sucessfully
- STLport: Got the source and did that configure thing - but actually
I don't exactly know (or remember) what this produced. Anyway there
is an STLport folder now.
- libxmi: Got the source and unzipped it. Is this it?
This is where I stopped and the last question was, whether I should do anything more than unzipping it:
>>>>> 2. libxmi-1.2
>>>> In the INSTALL file it says
>>>> 1. Do './configure', 'make', and 'make install', as usual. This
>>>> will install both libxmi and its header file, xmi.h.
>>>> but I'm not sure if "installing" is what I want to do in this case.
>>
>> these are standard instruction for Linux/Unix. They don't work for
>> MSVC. Also IIRC you just want to unpack it there, not necessarily
>> build/install it. But I may be wrong. I'm currently on Linux and it's
>> late. I shall look at my Windows box soon.
> OK, let's keep this one for later.
Just to verify that MSVC doesn't complain any more about missing things that I believe I solved I reran a build. The logs are below.
First thing I wondered about is that two projects are built: first vigra_impex and then enblend. But I found out that I have to chose from a submenu to build only a certain part.
Next thing is that it complains about missing tiff.h when building vigra. There was still tiff-3.8.2 listed in it's properties and with changing it to 3.9.1 this was solved.
(Updated moving_target.html accordingly.)
Building enblend didn't fail any more because of some dependency missing but because of too many other errors occurring. I put the complete log at http://www.joachimschneider.info/BuildLog.htm, but beginning and end are cited here:
2>------ Erstellen gestartet: Projekt: enblend, Konfiguration: Release Win32 ------
2>Kompilieren...
2>cl : Befehlszeile warning D9035 : Die Option "Wp64" ist veraltet und wird in einer der n chsten Versionen entfernt.
2>getopt_long.c
<snip>
2>d:\huginbase\lcms-1.18\include\icc34.h(781) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'count'
2>d:\huginbase\lcms-1.18\include\icc34.h(781) : fatal error C1003: Mehr als 100 Fehler gefunden; Kompilierung wird abgebrochen.
Ergebnisse Das Buildprotokoll wurde unter "file://d:\huginbase\enblend\src\Release\BuildLog.htm" gespeichert.
enblend - 264 Fehler, 1 Warnung(en)
I'm not sure if this is some progress. But at least it is a new kind of failing. I don't know if MSVC had found anything else missing if it hadn't stopped at some point. (Probably this is configurable, but I didn't find where.)
Look at the diff files for libxmi-1.2 and lcms-1.18
tiff.h can be found in wxWidgets, unless you're specifically linking against
a newer version for the larger file support (note: if doing so, make sure
you're not duplicating symbols in wxWidgets)
> -----Original Message-----
> From: J. Schneider [mailto:j-schn...@gmx.de]
> Sent: Sunday, November 15, 2009 4:49 PM
> To: hugin-ptx@googlegroups.com
> Subject: Re: [hugin-ptx] Re: (Probably very basic) help needed for
> build process on WinXP: missing files?
> Hallo Yuv,
> I took my moving_target.html and my huginbase directory to reconsider
> where I was standing.
> - trying to build enblend
> - lcms built successfully
> - wxWidgets found again after it looked like missing
> - libtiff built sucessfully
> - STLport: Got the source and did that configure thing - but
> actually
> I don't exactly know (or remember) what this produced. Anyway
> there
> is an STLport folder now.
> - libxmi: Got the source and unzipped it. Is this it?
> This is where I stopped and the last question was, whether I should do
> anything more than unzipping it:
> >>>>> 2. libxmi-1.2
> >>>> In the INSTALL file it says
> >>>> 1. Do './configure', 'make', and 'make install', as usual. This
> >>>> will install both libxmi and its header file, xmi.h.
> >>>> but I'm not sure if "installing" is what I want to do in this
> case.
> >> these are standard instruction for Linux/Unix. They don't work for
> >> MSVC. Also IIRC you just want to unpack it there, not necessarily
> >> build/install it. But I may be wrong. I'm currently on Linux and
> it's
> >> late. I shall look at my Windows box soon.
> > OK, let's keep this one for later.
> Just to verify that MSVC doesn't complain any more about missing things
> that I believe I solved I reran a build. The logs are below.
> First thing I wondered about is that two projects are built: first
> vigra_impex and then enblend. But I found out that I have to chose from
> a submenu to build only a certain part.
> Next thing is that it complains about missing tiff.h when building
> vigra. There was still tiff-3.8.2 listed in it's properties and with
> changing it to 3.9.1 this was solved.
> (Updated moving_target.html accordingly.)
> Building enblend didn't fail any more because of some dependency
> missing
> but because of too many other errors occurring. I put the complete log
> at http://www.joachimschneider.info/BuildLog.htm, but beginning and end
> are cited here:
> 2>------ Erstellen gestartet: Projekt: enblend, Konfiguration: Release
> Win32 ------
> 2>Kompilieren...
> 2>cl : Befehlszeile warning D9035 : Die Option "Wp64" ist veraltet und
> wird in einer der nächsten Versionen entfernt.
> 2>getopt_long.c
> <snip>
> 2>d:\huginbase\lcms-1.18\include\icc34.h(781) : error C2146:
> Syntaxfehler: Fehlendes ';' vor Bezeichner 'count'
> 2>d:\huginbase\lcms-1.18\include\icc34.h(781) : fatal error C1003: Mehr
> als 100 Fehler gefunden; Kompilierung wird abgebrochen.
> Ergebnisse Das Buildprotokoll wurde unter
> "file://d:\huginbase\enblend\src\Release\BuildLog.htm" gespeichert.
> enblend - 264 Fehler, 1 Warnung(en)
> I'm not sure if this is some progress. But at least it is a new kind of
> failing. I don't know if MSVC had found anything else missing if it
> hadn't stopped at some point. (Probably this is configurable, but I
> didn't find where.)
> Can you give me the next hints?
> regards
> Joachim
> --
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
> I took my moving_target.html and my huginbase directory to reconsider
> where I was standing.
One more thing that I noticed:
In the properties of enblend I don't see come include folders any more that used to be listed there (at least according to my email): glew and glut. No clue why, but I'll add them again.
..\..\glew\include
..\..\glut\include
> Look at the diff files for libxmi-1.2 and lcms-1.18
> tiff.h can be found in wxWidgets, unless you're specifically linking against
> a newer version for the larger file support (note: if doing so, make sure
> you're not duplicating symbols in wxWidgets)
To be honest, this is far beyond my level of skills. I'm not a programmer at all. (You can't count the remainders of some TurboPascal from the late 80s.) So I barely know what a diff is, let alone read it. Neither do I have a clue what a symbol is (I would guess some kind of variable).
My trying to build hugin is something like the effort to make an SDK or a documentation that is foolproof, and I kind of volunteer as the fool needed therefore ...
But do I understand you correctly: If I have tiff-3.xx listed separately in my list of include directories (instead of wxWidgets-2.8.10\include\wx where tiff.h is found as well) something can go wrong or special measures have to be taken. I think Yuv said that the larger file support (and some other improvements?) make it worth while using the latest tiff version. What would I have to do to avoid duplicating symbols - or would using the wxWidgets version be a shorter (though less perfect) solution to a working build?
And: would using the wxWidgets version work just as simple as putting wxWidgets-2.8.10\include\wx into the include list instead of tiff-3.xx?
|
