[Top][All Lists]
[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