On 03/25/2010 09:26 AM, Martin Paljak wrote:
> On Mar 24, 2010, at 21:55 , Alon Bar-Lev wrote:
>> I just provide them because after I rewrote the opensc build
>> system, there was no reason to maintain parallel build system for
>> windows only, and the windows build was unmaintained anyway.
> Right, the "problem" here being that there has never been no "windows
> build system". It has always only been "possible to build the code
> with visual studio".
>
> That's OK, as long as we can provide working binaries. One option
> would be to have an alternative build system for native build, like
> CMake (in addition to the autotools stack). I remember somebody
> showing interest in providing a cmake build solution as well.

I think it would be a pretty good idea to replace the current native
Windows build system (nmake) with something like CMake:

1) Current nmake build files are partially generated by autotools, so
it's not possible to build opensc on Windows without first bootstrapping
it with autotools.

2) OpenSC nmake build files are unmaintained. This is not really a
surprise: nmake is Windows-only, and as most of the opensc developers
are Linux/Mac users, they have no way of testing any changes to nmake
build files. Usually someone updates the files blindly, without having
any idea if they really work.

3) I'd say that most Windows developers prefer to use Visual Studio for
both editing code and building it, but having nmake build files (mostly
meant for being invoked on command line) doesn't make their life any easier.

4) Current nmake build files don't support building for 64 bit Windows
(there's no official 64 bit Firefox release, so it's not much of a
problem right now for most of the users).

5) One HAS to edit the build files in order to use the nmake build. See
my sed command which I use to configure opensc at the end of this mail.
Having to do something like that is not user friendly.


CMake is a cross-platform tool for first configuring a project and then
generating native build files. It can generate GNU Makefiles, nmake
makefiles, Visual Studio projects, XCode projects, and more. I think it
would be a pretty good idea to replace the unmaintained nmake build
files with CMake. If it's done properly, people could easily test their
build system changes on Linux, and it would automagically also work on
Windows.

If nobody else steps up, I could try to write some cmake build files.



This is how I configure opensc build on Windows currently:
         mv win32\Make.rules.mak win32\Make.rules.mak.orig
         sed < win32\Make.rules.mak.orig > win32\Make.rules.mak \
             -e "s|^LIBLTDL_INCL.*|LIBLTDL_INCL = /I$(LIBLTDL_INC)|" \
             -e "s|^LIBLTDL_LIB.*|LIBLTDL_LIB = $(LIBLTDL_LIB)|" \
             -e "s|^OPENSSL_INCL_DIR.*|OPENSSL_INCL_DIR = 
/I$(OPENSSL_STATIC_INC)|" \
             -e "s|^OPENSSL_LIB.*|OPENSSL_LIB = $(OPENSSL_STATIC_LIB) 
user32.lib advapi32.lib|" \
             -e "s|^#OPENSSL_DEF|OPENSSL_DEF|" \
             -e "s|^#ZLIB_DEF|ZLIB_DEF|" \
             -e "s|^ZLIB_INCL_DIR.*|ZLIB_INCL_DIR = /I$(ZLIB_INC)|" \
             -e "s|^ZLIB_LIB.*|ZLIB_LIB = $(ZLIB_LIB)|" \
             -e "s|^ICONV_INCL_DIR.*|ICONV_INCL_DIR = /I$(LIBICONV_INC)|" \
             -e "s|^ICONV_LIB.*|ICONV_LIB = $(LIBICONV_LIB)|" \
             -e "s|^#ICONV_DEF|ICONV_DEF|" \
             -e "s|/MACHINE:IX86|$(MACHINE)|"
         @for %f in ( src/scconf/Makefile.mak src/pkcs11/Makefile.mak 
src/common/Makefile.mak ) do \
                 mv %f %f.orig && \
                 sed < %f.orig > %f \
                     -e "s|/machine:ix86|$(MACHINE)|"

-- 
Kalev
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to