Re: Small build changes for win32

[Simon Josefsson]

"Christian Ehrlicher" <address@hidden> 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.

/Simon