help-libidn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Small build changes for win32


From: Christian Ehrlicher
Subject: Re: Small build changes for win32
Date: Fri, 31 Aug 2007 11:59:39 +0200

> Von: Simon Josefsson
> "Christian Ehrlicher" writes:
> 
> F>> Von: Simon Josefsson
> >> "Christian Ehrlicher" writes:
> >> 
> >> > Hi,
> >> >
> >> > To properly build (and link against) libidn on win32, I had to change
> >> lib\stringprep.h.in . The problem is that exporting data on win32 is a
> mess
> >> :)
> >> >
> >> > See attached patch, it's against 1.0.
> >> 
> >> Hi!  Thanks for the patch.  I am sorry for the slow reply, for some
> >> reason your e-mail didn't arrive at gmane.org where I read this list,
> >> but I found it in my mailman moderator queue and in the web archives.
> >> 
> >> I'd prefer if LIBIDN_DATA_EXPORT evaluated to the empty string on
> >> non-win32 systems, rather than to 'extern const'.  It seems in your
> >> approach you lose the 'extern' and 'const' specifiers.  At least
> 'const'
> >> seems important.  Would the following alternative approach still work
> on
> >> win32?
> >> 
> >>  // we need this little hack to export/import data properly
> >>  #ifdef _WIN32
> >>  # ifndef BUILD_LIBIDN_LIB
> >>  #  define LIBIDN_DATA_EXPORT __declspec(dllimport)
> >>  # endif
> >>  #endif
> >> ...
> >>  extern const LIBIDN_DATA_EXPORT Stringprep_profiles
> >> stringprep_profiles[];
> >> ...
> >> 
> > That's really the better solution (and works fine with msvc &
> > mingw). Don't know why I removed the const - imho gcc throwed a
> > compiler error and then I gave up :)
> 
> OK, good.  I'll see if I can incorporate something similar.
> 
> > btw: Do you plan to add cmake buildsystem support? It would be nice
> > for us win32 users and would help us to automate packaging for
> > http://download.cegit.de/kde-windows/win32libs/zip/single/
> 
> If you contribute patches to do it, I'll review them. :)
> 
> I don't want to add a lot of hacks for win32, but if the modifications
> are in separate files, like a top-level windows makefile or something,
> then that's not a problem.
> 
> I don't know much about Windows so I'm relying on you and others to tell
> me about things that are broken and to send patches.
> 
cmake is not a windows-only solution - kde is using it as their new buildsystem 
for 4.0.
I'll try to create a cmake script (one file + .h.in files adopted for cmake) 
when I've some time. You can then put it into the contrib subdir if you want.

The library can be used on win32 without any further modifications (at least 
I'm not aware that there we need some), the only thing msvc does not provide is 
stdint.h for (u)intXX_t types. But this can be solved easily without touching 
your code.


Christian

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail




reply via email to

[Prev in Thread] Current Thread [Next in Thread]