taglib on windows with visual studio

[Roel]

Hello,

I've been trying to get taglib to compile with MS Visual Studio (version 
.Net 2003). My goal was to not have to make any changes to the taglib 
sources but unfortunately I cannot seem to find a way to get that done. 
I did manage to get the sample running but the problems I encountered 
were as follows:
- There is no unistd.h on windows. That wasn't too bad, I just created a 
subdirectory 'win32' in the sources (at the root level of the tarball) 
and placed a file called unistd.h there, with the following content:

#include <io.h>

const W_OK = 2;
const R_OK = 4;

#define access _access
#define ftruncate _chsize

The last two defines are to cater for the different names of those two 
functions on windows.

- The config.h file is missing. On Unix it is of course generated by the 
autotools but I didn't want to use Cygwin. I made an empty config.h 
file, all I could see in the sources was that the file is used to check 
whether or not zlib support should be compiled in. So for now I've 
disabled that, it's easy to add support for it.

- The taglib source is organized so that it expects every directory to 
be present in the include search path. (-I on gcc). This is a pita; I 
had to add every directory to the project file (I didn't want to resort 
to command line builds). Is there a reason for this behaviour? I've seen 
it mentioned in the docs, as well as the included tool for listing all 
the directories, but I don't see the use of it. If it's to allow easy 
reorganization of the source files: how often does that happen? And if 
it must happen, it can't be more than 15 minutes work to change relative 
paths.

- Then finally, the biggest problem. Because of the license of taglib I 
needed to compile it as a dll. But on windows for the creation of dlls, 
one needs to mark all symbols to be exported with __declspec(dllexport). 
This requires modifying the taglib sources. So I tried to circumvent it 
by trying to use Cygwin's dlltool and dllwrap to create the .lib file. 
I've tried all sorts of combinations of command line options and I 
succeeded in getting the tagreader sample to compile and link with a 
.lib generated by dlltool, but the testprogram would crash right after 
startup. If someone knows a way to generate a .exp file (or .lib) from a 
.dll and/or .map file, please let me know.
Anyway since I couldn't get it work I've resorted to adding a macro to 
the taglib sources:

#ifdef TAGLIB_EXPORTS
#define TAGLIB_EXPORT __declspec(dllexport)
#else
#define TAGLIB_EXPORT __declspec(dllimport)
#endif

and then add TAGLIB_EXPORT to the classes that need to be exported, as such:

   class TAGLIB_EXPORT String

Now I have the tagreader.cpp sample running. (but only with the 
single-threaded runtime dlls, but that's ok for now).

Now I would still like a solution where I don't have to create my own 
version of taglib every time a new version comes out. Options are:
- A change of the taglib license to allow static linking without 
requiring the main application to be LGPL/GPL. That would make static 
linking a viable option for me, but it's probably not an option for the 
authors of this fine library :)
- Finding a tool that will allow generation of .libs from dlls without 
exported symbols. Don't know if it's possible.
- Add the above-mentioned macros to the source code. It would add around 
20 or so lines of macro code. I don't know what the standpoint of the 
taglib author is on this? It wouldn't require much maintenance and would 
be very unobstrusive; in addition to the macros there would only be one 
new toplevel directory with the Visual Studio project files for the 
library and the samples and the unistd.h and config.h files.

Failing this I'm willing to create a version of taglib that has the 
above changes and provide dll's on my own website, but of course if at 
all possible I'd like to avoid the work.

This mail is probably getting way too long so I'll cut it off; are there 
any other VS users on this list who have any ideas or opinions on the 
points I raised?


cheers,

roel