[Nice] R: various patches for Windows / Visual Studio compilation
Della Betta Filippo
filippo.dellabetta at telecomitalia.it
Wed Feb 15 02:01:17 PST 2012
First patch, let me know if it is the right format and indentation
Filippo Della Betta
Da: Della Betta Filippo
Inviato: mercoledì 15 febbraio 2012 09:54
A: 'Youness Alaoui'; nice at lists.freedesktop.org
Oggetto: R: [Nice] various patches for Windows / Visual Studio compilation
Filippo Della Betta
Da: nice-bounces+filippo.dellabetta=telecomitalia.it at lists.freedesktop.org [mailto:nice-bounces+filippo.dellabetta=telecomitalia.it at lists.freedesktop.org] Per conto di Youness Alaoui
Inviato: martedì 14 febbraio 2012 19:17
A: nice at lists.freedesktop.org
Oggetto: Re: [Nice] various patches for Windows / Visual Studio compilation
On 02/14/2012 09:11 AM, Della Betta Filippo wrote:
> attached you can find some patches that issue some Windows / Visual
> Studio compilation problem
>>Thanks, however, like I asked Rohan and Madaro, could you make those git patches, as it makes it easier to apply, also, separate each patch into its own commit.
Ok, can anyone suggest me how to do that ? I'm quite new to git. I've tried git format-patch but I didn't succeed.. Should I make a branch ?
Moreover, is it possible to reach the git repository via http ? we have a http proxy that allows only http/https..
> In particular
> - On file agent.c and tcp-bsd.c , as glib documentation suggests
> g_io_channel_unix_new should be avoided. Replaced with
> g_io_channel_win32_new_socket function on WIN32 platform
>>Good, but you broke the indentation in the file, please fix it to be indented like the rest of the file.
Ok, I'll do that
> - On file pseudotcp.c, since Visual Studio compiler does not support
> C99 I put some declarations at the beginning of the statement.
> Moreover I expanded the macro g_debug to make Visual Studio happy. I
> tested it on mingw/msys and seems ok
>>Good catch, but like before, you broke the indentation in the file.
>>However, I don't understand why you had to expand the g_debug macro, you should not have to do that.
I think it's a Visual Studio compiler problem regarding the __VA_ARGS__ macro, with g_debug it doesn't compile...
Maybe someone has a better idea how to fix that..
> - On file sha1.h, I included the replacement header win32_common.h
> instead of the missing header stdint.h (at least on Visual Studio).
> - On file win32_common.h I added , if not defined, typedef on size_t
> and ssize_t that are not defined on Visual Studio platform, I tested
> it on mingw/msys as well and seems ok
> - On files test-*.c : most of the time WSAStartup is missing (causing
> test to fail immediately) , on test-pseudotcp.c EWOULDBLOCK is not defined.
> Moreover __func__ is missing and is replaced by __FUNCTION__
>>Good point about WSAStartup, not sure though if those should be put in the tests or if it should be in libnice. Technically libnice does it when it discovers the interfaces, however those >>unit tests are forcing the use of 127.0.0.1, that's why it's not used, so maybe it's ok to leave it in the unit tests. In which case, it would be a good thing to add a note to the >>nice_agent_add_local_address documentation explaining that if it's used, then WSAStartup should be used on windows.
For my experience, WSAStartup is usually put on a "init" library function and WSACleanup on "deinit" library function, otherwise you could add a note to every function that use socket that WSAStartup should be called first
>>Also, why do you do :
>>+ WSADATA w;
>>+ WSAStartup(0x0202, &w);
>>Instead of doing :
>>+ WSADATA w;
>>+ WSAStartup(0x0202, &w);
Only to separate declaration from code.. In this case is the same
>>I don't understand though why you replaced G_STRFUNC with __func__ since that glib macro should take care of it and should be defined properly depending on your compiler.
G_STRFUNC doesn't work for me (it prints ??? instead the name of the function), I will look more in detail to see how to make it work on Windows..
Anyway in other test you use only __func__, that's why I redefined __func__
>>About the EWOULDBLOCK, I wonder if pseudotcp.h shouldn't have those defines instead, so every user of the lib wouldn't need to define them. What do you think?
I think it's ok!
> If you are interested, I can provide you with vcproj and/or sln files
> for Visual Studio 2008 (as well as config.h specific for Visual
>>Yes, I think it would be a good idea to put those files under a win32 directory, maybe with a README.win32 file if you think it's necessary.
> Filippo Della Betta
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please delete
> this message and any attachments and advise the sender by return
> e-mail, Thanks./
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
> non è
> nice mailing list
> nice at lists.freedesktop.org
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1718 bytes
More information about the nice