On Dienstag, 19. Februar 2019 20:22:42 CET Christian Schoenebeck wrote:
> On Montag, 18. Februar 2019 16:09:11 CET justnope wrote:
> > This is the final version. I did several tests and they all seem to work.
> >
> > If you remove the MSVC check in CMakeLists.txt it will also compile the
> > libra
On Montag, 18. Februar 2019 16:09:11 CET justnope wrote:
> This is the final version. I did several tests and they all seem to work.
>
> If you remove the MSVC check in CMakeLists.txt it will also compile the
> library and some tools in linux.
I'm currently processing Ivan's patch, but I am optim
On 15/02/2019 16:00, justnope wrote:
On 15/02/2019 15:15, Christian Schoenebeck wrote:
I suggest that I commit your msvc patch first, and then sure, if you
like to
adapt the cmakes for other architectures, very much appreciated of
course!
So your previous patch sent to the list is the lates
On 15/02/2019 15:15, Christian Schoenebeck wrote:
I suggest that I commit your msvc patch first, and then sure, if you like to
adapt the cmakes for other architectures, very much appreciated of course!
So your previous patch sent to the list is the latest one, or should I wait
for an updated pat
On Freitag, 15. Februar 2019 15:04:47 CET justnope wrote:
> On 14/02/2019 17:03, Christian Schoenebeck wrote:
> > Ok, then just leave the cmake files at their locations as you did. Then
> > later on we try to make them shared ones for other architectures as well.
> I can adapt the cmake files to bu
On 14/02/2019 17:03, Christian Schoenebeck wrote:
Ok, then just leave the cmake files at their locations as you did. Then later
on we try to make them shared ones for other architectures as well.
I can adapt the cmake files to build for other systems now if you'd
like. This means I'll have to
On Mittwoch, 13. Februar 2019 18:58:25 CET justnope wrote:
> I also work on lmms and there we compile for windows, mac, linux. For
> windows we can cross-compile with mingw or use msvc directly. This is
> done with shared cmake files for all combinations. If there's a
> limitation, I haven't encoun
I found a mistake which resulted in a compile error when I tried it with
gcc, added an install option in the cmake file and split it into libgig
& libakai so it's the same as the makefile.
On 12/02/2019 17:37, Christian Schoenebeck wrote:
Looks fine to me. Just one last thing: You added CMake
On Montag, 11. Februar 2019 14:49:22 CET justnope wrote:
> Could you check the attached patch for possible mistakes or things you'd
> like to see implemented differently?
Looks fine to me. Just one last thing: You added CMake files and I wonder
what's
better, placing those CMake files directly a
Hi,
Could you check the attached patch for possible mistakes or things you'd
like to see implemented differently?
About the directory functions (opendir,...), I'm currently also porting
zynaddsubfx to msvc and have a partial implementation ready. As soon as
it's complete, tested and approved
On Freitag, 8. Februar 2019 01:03:59 CET justnope wrote:
> > Yes, that makes sense. Would you also share your real name so I can
>
> credit you
>
> > for your patch?
>
> I'm fine with being uncredited or using justnope.
Committed, slightly modified. Thanks!
I figured we should fix the same i
> Yes, that makes sense. Would you also share your real name so I can
credit you
> for your patch?
I'm fine with being uncredited or using justnope.
Another thing I noticed but I'm unable to test is that in
Serialization.cpp the return value of abi::__cxa_demangle isn't freed.
On 03/02/20
On Montag, 4. Februar 2019 05:34:07 CET justnope wrote:
> This patch has nothing directly to do with the msvc development. I
> noticed it when I was trying out the GigWriteTest.
>
> Depending on the constructor, RIFF:File can be allocated by the
> constructor or passed on. In case DLS::File alloca
Hi,
This patch has nothing directly to do with the msvc development. I
noticed it when I was trying out the GigWriteTest.
Depending on the constructor, RIFF:File can be allocated by the
constructor or passed on. In case DLS::File allocates RIFF::File itself,
it never gets destroyed. This res
On Saturday, 2. Februar 2019 02:53:14 CET justnope wrote:
> > 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.
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
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 replacin
Hi,
This is a first attempt to compile the library with msvc.
The changes are:
* ssize_t -> size_t
* vasprintf -> vsnprintf, malloc, sprintf
* removed unavailable headers
* added cmake file
To compile it, use cmake . This will generate a visual
studio solution file which you can open and build
Hi,
This is a first attempt to compile the library with msvc.
The changes are:
* ssize_t -> size_t
* vasprintf -> vsnprintf, malloc, sprintf
* removed unavailable headers
* added cmake file
To compile it, use cmake . This will generate a visual
studio solution file which you can open and build
19 matches
Mail list logo
