[SCM] exiv2 packaging branch, master, updated. debian/0.25-3.1-3734-gdcbc29a
Maximiliano Curia
maxy at moszumanska.debian.org
Thu Jul 13 17:40:02 UTC 2017
Gitweb-URL: http://git.debian.org/?p=pkg-kde/kde-extras/exiv2.git;a=commitdiff;h=e3fda02
The following commit has been merged in the master branch:
commit e3fda02d87ce70a48d90a67ce88cbb8c37742fed
Author: Andreas Huggel <ahuggel at gmx.net>
Date: Sun Nov 2 12:43:52 2008 +0000
Minor changes.
---
msvc/README-MSVC.txt | 46 +++++++++++++++++++++++++++-------------------
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/msvc/README-MSVC.txt b/msvc/README-MSVC.txt
index 5c78eff..950ac01 100644
--- a/msvc/README-MSVC.txt
+++ b/msvc/README-MSVC.txt
@@ -1,9 +1,6 @@
Notes about msvc build of exiv2
-------------------------------
-CodeBase: exiv2 /trunk: 1652
-Version : Tuesday 20081030 at 20:55PDT
-
Tools
-----
@@ -16,25 +13,27 @@ How to build and test
---------------------
1) Dependancies
- You need expat-2.0.1 AND zlib which you can download from sourceforge
- expat-2.0.1, zlib and exiv2 should be in the same directory
+ You need expat-2.0.1 AND zlib-1.2.3 which you can download from http://expat.sourceforge.net/
+ and http://zlib.net/, respectively. expat-2.0.1, zlib and exiv2 should be in the same
+ directory
- I usually use c:\gnu, however the name does not matter
- nor does it have to be a topmost directory
+ I usually use c:\gnu, however the path 'c:\gnu' does not matter
+ nor does it have to be a topmost directory.
c:\gnu\expat-2.0.1 <---- vanilla expat
c:\gnu\zlib <---- vanilla zlib
c:\gnu\exiv2 <---- this directory
-2) Convert expat-2.0.1 VC6 work space your version of DevStudio
+2) Build expat. See there for details. Something like this usually works:
+ Convert expat-2.0.1 VC6 work space your version of DevStudio
Open expat-2.0.1\expat.dsw with DevStudio to convert and save the expat project files
Say "Yes" to everything.
-
+
Build/Batch Build/Select { debug | release } { expat | expat-static } (4 targets) / Build
-
+
Rattle roll.... less than a minute ...... rattle grrrrrrrr rump.
========== Build: 4 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
-
+
3) Open the sln file exiv2\msvc\exiv2.sln
On VS2005 and up, the Wizard will offer to upgrade the project files.
Once more, say yes to everything.
@@ -60,13 +59,13 @@ How to build and test
The total build consumes 1.2GBytes of disk space.
There are 94 targets.
The pdb (debugging) files consume 400MBytes.
- The debug exiv2 library (exiv2.lib) is 40mBytes
-
+ The debug exiv2 library (exiv2.lib) is 40MBytes
+
A more modest build is to build exiv2 { Debug | Release | DebugDLL | ReleaseDLL }
- This consumes: 420mBytes
+ This consumes: 420MBytes
A minimum build is to build exiv2/Release
- This consumes: 100mBytes
+ This consumes: 100MBytes
I will reduce this by about 10-20% in 0.18final (see appendix)
@@ -159,8 +158,8 @@ To be done (hopefully for 0.18final)
- Do some debugging (check that it debugs, links, builds OK)
- Test more 'partial' targets
- See what happens when expat isn't built!
-3 Make the test program much longer and deeper
-4 Investigate the crashes in the DLLs (see Known Issue)
+3 Investigate the crashes in the DLLs (see Known Issue)
+4 Make the test program much longer and deeper
5 Build and test pyexiv2 and exiv2net
- We're not going to distribute pyexiv2 or exiv2net
- I'd like to test that those work correctly with our builds
@@ -175,7 +174,16 @@ APPENDIX
zlib4exiv2.dll
--------------
-The 'vanilla' zlib projects build zlib1.dll and zlib1d.dll. (d=debug). These are built with the MD (and MDd) options. We are building with MT and MTd. When we link, we get heart-thumping warnings from the linker about malloc and free. I don't think it's a good idea to link those. So, I added a project zlib4exiv2 to build the MT (and MTd) version of zlib. I resisted the temptation to call those zlib1.dll (and zlib1d.dll) as they are different from the 'vanilla' versions. While I believe zlib1.dll and zlib4exiv2.dll are probably interchangeable, I decided not to take the risk of breaking another product by redefining a 'standard' dll. Rule 1 in life 'do no harm'.
+The 'vanilla' zlib projects build zlib1.dll and zlib1d.dll. (d=debug).
+These are built with the MD (and MDd) options. We are building with
+MT and MTd. When we link, we get heart-thumping warnings from the
+linker about malloc and free. I don't think it's a good idea to link
+those. So, I added a project zlib4exiv2 to build the MT (and MTd)
+version of zlib. I resisted the temptation to call those zlib1.dll
+(and zlib1d.dll) as they are different from the 'vanilla' versions.
+While I believe zlib1.dll and zlib4exiv2.dll are probably
+interchangeable, I decided not to take the risk of breaking another
+product by redefining a 'standard' dll. Rule 1 in life 'do no harm'.
I need to do more work in this area.
@@ -187,6 +195,6 @@ At the moment, I build every target into it's own directory and then copy it to
For example: exiv2/msvc/exiv2.lib -> debug/exiv2.lib = copy => exiv2/msvc/bin/debug/exiv2.lib
I did this for a good reasons at the time. I think I'll revisit this and build into the bin.
-This will save about 100-200mb of disk space on a complete build (10%-20%)
+This will save about 100-200MB of disk space on a complete build (10%-20%)
-- end --
--
exiv2 packaging
More information about the pkg-kde-commits
mailing list