On Dienstag, 29. Januar 2019 04:14:41 CET justnope wrote: > Hi, Hi!
> This is a first attempt to compile the library with msvc. > The changes are: > * ssize_t -> size_t size_t is an unsigned type, whereas ssize_t is signed. So these two types are used in the code for purpose and simply replacing one with the other would break things, especially replacing ssize_t by size_t is not a good idea. It would make more sense to find an equivalent type available with msvc and to add an appropriate typedef for msvc instead. > * vasprintf -> vsnprintf, malloc, sprintf If vasprintf() is missing then it would be preferable to add an implementation of vasprintf() for msvc (e.g. in helper.h/.cpp) instead of bloating all the calling code locations in RIFF.cpp and Serialization.cpp. > #if defined(WIN32) && !HAVE_CONFIG_H > +#if _MSC_VER > +//PACKAGE and VERSION are defined using the cmake file > +#else > > # include "../win32/libgig_private.h" // like config.h, automatically > generated by Dev-C++ # define PACKAGE "libgig" > # define VERSION VER_STRING // VER_STRING defined in libgig_private.h > > +#endif // _MSC_VER > #endif // WIN32 Well, you know the problem here is who would update all the individual version numbers at separated places, for each combination of platform and build tool on every release. I rather would like to reduce the number of places where we need to bump version numbers instead of adding yet another one. Does msvc not ship with autoconf at all? If not, maybe a small script triggered by the msvc project or by cmake might be an alternative that would grep the latest version number from configure.ac? > * added cmake file > > To compile it, use cmake <source dir>. This will generate a visual > studio solution file which you can open and build the project. In the > cmake file I've added the option to make all symbols in the library > public (or whatever the right term is), so it behaves like gcc. This > avoids polluting the source code with DLL_EXPORT defines > (__declspec(dllexport/dllimport)). The term is "exporting" symbols. And what you did is adding a compiler option which exports all symbols automatically to the generated DLL. Essentially exporting means that e.g. functions and global variables are written to a table in the DLL file. The table contains the symbol name (function name, variable name) and how it can be found (address) by applications using the DLL. Usually one would pick a compiler option to export only global symbols, not all symbols. If you pick all symbols it would also export private (static), implementation internal functions and variables, not meant to be accessed from outside. > There's also a message in the source code "type_info::raw_name() > demangling has not been tested yet with Microsoft compiler! Feedback > appreciated!" I see that you actually disabled demangling completely for msvc. I am not sure, but isn't there an alternative function for mscv that's called undecorate symbols "unDec" or something? At least that's what I found somebody suggested on the net. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
