Darshaka Pathirana wrote:
Hi!
Hello,
Success!
great!
Finally I was able to fully build the latest wengophone-2.2 revision
with Visual Studio 2005 Express Edition!
First of all I would like to refine my first post[1] with a few
corrections:
1. I used wengophone-2.2 (rev 13252) instead of (rev 13237)
2. You actually you do NOT need to change the C:\Program
Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat file for
this project.
vsvars32.bat actually only needs to be modified if you want to use the
Platform SDK and/or DirectX SDK and want to compile your programs on the
command line.
So just let all of the given environment variables be set by the system
and add the Include and Lib-paths as described in Visual Studio C++
2005.
Ok. As promised I attached my patchset for revision 13253 of
wengophone-2.2. I'll try to explain what happened and what I have
changed. I also may have questions and I by no means think that this is
the ultimate solution. So if you think you can pinpoint what could be
done better I would be very glad!
Basically you can follow steps 1 to 7 from my first post[1] except for
my corrections above. Let's continue with the next steps:
8. Patch the files
As mentioned just apply my attached patchset
(wengophone_2.2_r13252_dpat-2.diff). This can easily be done with
TortoiseSVN. Right-click on the wengophone-2.2 folder, click Apply
patch.. and choose the file. After that you will see a popup file
patches. Just right-click on it and choose Patch all. Done!
9. Configure wengophone (create Visual Studio Project files):
9a. Run C:\Projects\wengophone-2.2\build\create_vcproj-VC80.bat
You can actually just double-click on it. vsvars32.bat is called out
of it. This should create the Visual Studio project files.
10. Open the project
The Visual Studio Solution is then located in the build-directory.
After opening it you'll notice a popup The solution already conatains
an item named 'lrelease'. That's not critical so just ignore it! (Maybe
somebody knows how to get rid of it.)
11. Build wengophone
You can either build the whole solution, the project ALL_BUILD or the
project WengoPhone. The safest bet would be to build the whole solution.
Actually all of Visual Studio project files / properties are also
rebuild (by some CMake-Magic) so it might be necessary to build
wengophone a second time. In fact you have to rebuild those projects
where you changed any of the cmake-files (or at least have to wait until
the initial configuration is done and start over).
After some time (go out and meet some friends ;) ) you should see a fine
built wengophone.exe in your build-directory.
12. Start it and have fun debugging...
Smaller patches than one big file would be nice.
Additional notes on my patchset:
- libs/3rdparty/qt4/CMakeLists.txt
Since a version of Qt 4.x the DLLs of the lib are now ending with a 4.
I have changed that accordingly.
Are you sure that this is the case for all released Qt version. Maybe the
others should stay in the code. I think if the file doesn't exist, it would
stop to work.
- libs/owutil/util/CMakeLists.txt
- libs/webcam/CMakeLists.txt
- wifo/phapi-util/CMakeLists.txt
The lib files of these projects are not created without these definitions.
I think this should be wrapped in an
if (WIN32)
endif (WIN32)
- owbuild/owbuild/OWCreateProjectBinary.cmake
This was tricky and I am still not absolutly sure about it. This patch
now enables the post-build-copy-process to copy the DLL and PDB files
from the correct directory (by taking the right buildtype (debug vs.
release) into account). Maybe someone can take a special look at this
one. Thanks!
Yes, the files should be copied to the build type directory (release, debug)
- wengophone/src/buildid/CMakeLists.txt
The Preprocessor Definition DD_BUILDID had two LL at the end (I
don't know why) but they should be an integer. The patch fixes that.
#define FOO 42LL means that FOO is a long long.
Current date and time is for example 20070127132638, this doesn't fit into an
integer you need a 64bit variable. That's why the function in
wengophone/src/WengoPhoneBuildId.cpp returns a long long.
const unsigned long long WengoPhoneBuildId::getBuildId() {
return DD_BUILDID;
}
So #define DD_BUILDID 2007012713263LL is right!
- wifo/owsl/src/core/owsl_address.c
OWSL_FUNC_DEF (which is definded as __declspec(dllimport)) is already
set in the header. No need to do that again.
- wifo/phapi/CMakeLists.txt
There two patches in here...
1. The lib file is not created without this definition.
Should be wrapped into if (WIN32)
2. The Visual C++ compiler option -D do strip the quotes on the
command line[2] so this must be handled by a define in phapi.c.
That's bad, have you tried to escape them? There should be another way to do
that.
-DWENGOPHONE_UA=\wengo/v1/wengophoneng/wengo/rev${SVN_REVISION}/trunk/\
or
