Remove binary blob in repository about libnfc HOT 19 CLOSED

From Comment 8 by [email protected] on Issue 12:
> I think you can consider removing everything from the win32 directory except 
the
> stdint directory, unless a 64 bit Windows version is a current feature. This 
requires
> some more work on the CMake files to find the correct library 32/64 bit 
libraries.
Yes, 64 bits Windows is a current feature. Do you suggest to remove all .vcproj 
files
too ? Don't Windows users need them to work with libnfc ?

Well, they can be generated by the CMake tool, for all versions of visual 
studio, and
some other compilers as well.

Hold this off until I get 64 bit stuff working then :-) I need to get a Windows 
64
bit installation somewhere first to really test it...

Patch here to update CMake files to search for 64 bit Windows libraries instead 
of 32
bit ones on windows 64 bit. This was not tested yet...

Also includes a README file for Windows, not sure where you want to place it, 
maybe
in the root, maybe in the win32 directory? Hopefully it will be useful. 

Hey Fkooman,
Thanks for this patch.
It have been applied in r103.
Note: I have fixed some typo in Windows README.

You forgot the cmake_modules directory and its files.

This patch updates build files some more, to make it more robust. Updated the
Windows-README extensively explaining how to build on Windows in detail.

This patch is against current SVN, so includes the cmake_modules directory 
again with
updated files!

The Windows README has now DOS line endings, maybe this is acceptable for you, 
if not
change it to Unix line endings :-)

You're right, I'm sorry.
BTW, your updated patch have been applied in r104.

I don't care about DOS line ending if files are Windows only.

Thanks.

There's a little problem I think. Only Windows XP is supported by the 
libusb-win32
filter, and it seems using it in Vista or Windows 7 will give problems (there 
you
should be able to use the driver). This however does not work on 64 bit Vista 
or 7
due to the driver not being signed which will make it impossible to load it.

You know of anyone using libnfc (or libusb for that matter) on 64 bit systems >=
WinXP? And whether this actually works?

- make libusb optional (still needs to be added to autotools stuff!) CMake 
defaults
to have libusb support off. You may want to make it default on for autotools 
stuff :)

This will benefit Windows (Vista, 7 and 64 bit) where libusb doesn't work 
(reliably)
and the Tikitag readers use PC/SC anyway which does work on everything.

Maybe sometime in the future someone should look into WinUSB support (as 
alternative
"backend" for libusb I guess). Outside scope here.

Applied in r106. I have had to patch README-Windows.txt file by hands, "patch" 
tool
seems to refuse to patch this file (and only this one) this time. But your patch
seems to be well made... Weird...
I suggest to use "examples" term to point binaries provided by libnfc since they
can't be consider as tools: i.e. target/initiator (except mftool and mfultool).

Added GNU Makefile for compiling in Windows without VC.
Just install the C++ compiler/headers from the "Microsoft Windows SDK v7.0" [1]

Start the "CMD Shell" and set your target architecture by running:
"setenv /x86 /release"
"setenv /x64 /release"

Then make sure you have a windows binary of GNU make[2][3][4] in your path.
And just run "make"

[1]
http://www.microsoft.com/downloads/details.aspx?FamilyID=c17ba869-9671-4330-a63e
-1fd44e0e2505&displaylang=en
[2] http://www.steve.org.uk/Software/make/make.zip
[3] http://gnuwin32.sourceforge.net/packages/make.htm
[4] http://www.mingw.org/wiki/msys

[deleted comment]

Roël, could you remove win32/libusb which mainly contains binaries and could 
you
clean up win32 directory (Are *.vcproj needed ?) ?

Roel had some issues with CMake not working for him, so I guess vcproj files are
required still if that issue can't be resolved. Roel: did you read the
README-Windows.txt? :-)

As for libusb: maybe a document that describes how to create a libusb driver 
from
scratch (in Windows) would be helpful (to make it work in 32 bit Vista/7?). 
I'll try
to look into that later.

We have to look into this windows "bla". It seems that the (64bit) driver of 
libusb
is not working because it is not signed. Therefor we may want to choose to 
build a
(default) libusb-less version for windows. But that would require a lot of 
explaining
in the community/docs :)

Anyway, besides this, we can build the windows version now using the (GNU) 
Makefile I
wrote and using the CMake wrapper. I'm not really a CMake guy, but if we can
"generate" installers that installs the include/lib in the place where it is 
needed,
I guess it would avoid a lot of questions.

What I hope to find is a way to AVOID mixing "environment" files with 
sourcecode. So
if windows CMake bla needs a "CMakeLists.txt" can't we move it a CMake dir in 
the
main package? Furthermore, can we also do this with the "Makefile.am" file? Or 
does
the package distributor requires that it is mixed into the sourcecode?

I guess it would be possible to do that, didn't look into that as all examples 
assume
the CMakeLists.txt is contained in the source directory. 

It would be really nice if it could be decided to use only one build system,
whichever of the two it is, because whenever a change to the Autotools makefile 
is
made, sometimes that change is also required in the CMakeLists.txt file which 
not
everyone understands or remembers. This sucks ;-) So if the Windows build works 
with
Autotools we may want to drop the CMake build files altogether, although I 
personally
think CMake would be nicer ;-) Big problem there is that it doesn't seem to 
work on
the OpenWRT stuff (and I don't have the time/build system to test cross platform
builds unfortunately)

CMake uses NSIS to create an installer for Windows, this works quite nice. But 
of
course it should not be to difficult to add a Makefile entry to generate a NSIS
configuration file to create a NSIS installer that way, but someone would have 
to
figure this out :)

Roel, why don't you want to "mix" sources and build system ? That's the way all
projects use... Why is it a problem ?
BTW, some Autotools files must be in top directory and Makefile.am must be in
directory which is rule by Makefile.am.

François, why is it a problem to support to have more than one build system, 
if we
maintain both ? Autotools are really tricky, really slow and this can be a 
headache
to fix some Autotools problems... but it works under many system, and it have a
well-know way to cross compile and I need it.
If we have to choose one build system, for libnfc users, it should be better to 
use
CMake: that more simple, it have GUI, it can work under fine old-generation-OS
(Windows) and it can produce installer.
But you have to know that I will continue to maintain Autotools files, I need 
to. If
you don't like them into official repository, I can maintain them under local 
repository.

Finally, I would like to say that it possible to provide CMake files with
Autotools-generated archive. This way, we just need to adjust instructions (i.e.
Autotools for POSIX system and cross-compiling, CMake for non-standard OS ;-) )
I think the first step is to avoid the use of "manual" makefiles, for all OSes 
and
Roel, you should use one of them (CMake or Autotools) instead of maintain 
another-way
build system :-) and second step is to have somebody to maintain CMake files (of
course, I will make some efforts to try to implement CMake files as Autotools).

> Roel, why don't you want to "mix" sources and build system?
Well, I kind of like the separation of the core source-code, to avoid any 
system and
environment dependency. It would be awesome to have a /src and /include 
directory in
the main package which contain only "sources" and "includes" and not 
environmental
Makefile-enries ....

> That's the way all projects use... Why is it a problem ?
In that case... I'm just a complaining bitch, so let's ignore me and go on with 
"da
facto standard" :)
I can better keep my attention on programming in stead of packaging! ;)

Can't we just use the MinGW environment on windows with autotools, I remember 
that
that worked fine for some other libs I ones tried to compile. To be honest, the
Windows developers probably only want the .lib/.dll/includes files to do there 
job.
They often don't care to much about (re)compiling the library itself. So maybe 
we
should give (compilation) less attention and invest it more in the "installer"?

Fixed when revamp source tree.