libfreefare's windows build (patch provided)

[GoogleCodeExporter]

Attached patch allows building libfreefare on windows.
This is based on the one in this thread 
http://www.libnfc.org/community/topic/284/libfreefare-on-windows/ , but now 
using a generated config.h.
Any comments welcome.

Original issue reported on code.google.com by glenn.er...@gmail.com on 13 Apr 2011 at 9:13

Attachments:

• 20110513.patch

[GoogleCodeExporter]

Original comment by romu...@libnfc.org on 21 Apr 2011 at 9:46

• Changed title: libfreefare's windows build (patch provided)
• Added labels: Type-Enhancement, Priority-Low, OpSys-Windows, Component-libfreefare
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Line 13: is EOPNOTSUPP defined on Windows?  On FreeBSD, ENOTSUP is defined as:

#define ENOTSUP     EOPNOTSUPP  /* Operation not supported */

(POSIX seems to give different means to these values but I don't think it is a 
big problem)

Moreover, I do not use Microsoft Windows and so won't test / update Windows 
build.  For this reason, I am OK to merge your patch only if you accept to 
maintain the Windows build (I don't say I won't help if you have a problem, but 
I don't want to add broken support for any plateform).  Are you akay for 
maintaing Windows support in the future?

Thanks!

Original comment by romain.t...@gmail.com on 23 Apr 2011 at 7:15

• Changed state: Feedback

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok, i found EOPNOTSUPP to be defined as WSAEOPNOTSUPP in some mingw-header. So 
maybe it is best to define to WSAEOPNOTSUPP on windows?

We will be using libfreefare for a desfire project for the next 2 years, so it 
important to me to keep up with the current trunk, and to keep it working on 
windows. I think keeping libfreefare portable should not be very difficult (i 
expect libnfc would require more work since it is closer to the hardware/OS 
imo).
What i will do (and already did for libnfc) is set up a nightly build on our 
build server which fetches the latest code from svn and builds it and 
(optionally) runs the unit tests, so that build errors or regressions can be 
caught quickly. And try to send patches to fix the build if needed of course :)

Original comment by glenn.er...@gmail.com on 24 Apr 2011 at 9:26

[GoogleCodeExporter]

I'll take it!

Original comment by romain.t...@gmail.com on 24 Apr 2011 at 10:15

• Changed state: Started

[GoogleCodeExporter]

This issue was updated by revision r789.

Gleen, I slightly modified your patches to better stick with the style of the
rest of the project,  Can you please confirm that it does not break?

PR:     Issue 62
Submitted by:   glenn.ergeerts

Original comment by rtarti...@il4p.fr on 24 Apr 2011 at 10:21

• Changed state: Feedback

[GoogleCodeExporter]

It does not build anymore, i think something went wrong with the paths:
- FindLIBNFC.cmake should be in cmake/modules directory
- config_windows.h.cmake should be in cmake/
- err.h should be in contrib/win32

or was this intentionally? Then i will adapt the cmake files to get it working 
again

Original comment by glenn.er...@gmail.com on 24 Apr 2011 at 6:56

[GoogleCodeExporter]

This issue was updated by revision r792.

Looks like I missed the -p0 argument to patch.  Can you please update and test?
Thanks!

Original comment by rtarti...@il4p.fr on 25 Apr 2011 at 10:38

[GoogleCodeExporter]

works now, thanks!

Original comment by glenn.er...@gmail.com on 25 Apr 2011 at 4:01

[GoogleCodeExporter]

Cool!  I close the issue then.

Thanks!

Original comment by romain.t...@gmail.com on 25 Apr 2011 at 10:29

• Changed state: Fixed