Re: [patch] port libffi to x86/msvc

[Mladen Turk <mturk at redhat dot com>]

On 01/15/2010 07:46 PM, Dan Witte wrote:
>> Thanks Dan -- I've checked this in.  I've also add the cc.sh script
>
> The '--enable-shared --enable-static' aren't necessary, I just happened to use them, so you may want to change that.
>

Just tried the build and the msvcc.sh breaks by the backslash chars,
so additional backslashes are needed since they are unescaped once
during eval and second time durig actual shell exec.
This ends up with cl failing with 'cannot find srcdebug.c'
which is actually src\debug.c unescaped.

diff --git a/msvcc.sh b/msvcc.sh
index 8301839..d841a3e 100755
--- a/msvcc.sh
+++ b/msvcc.sh
@@ -176,6 +176,7 @@ if [ -n "$assembly" ]; then
     #mv *.obj $outdir
 else
     args="$md $args"
+    args="$(echo $args | sed 's%\\%\\\\\\\\%g')"
     echo "$cl $args"
     eval "\"$cl\" $args"
     result=$?


Finally, the produced libffi-5.dll doesn't have any exported
symbols so it's basically unusable.
IMHO the real msvc makefile would be needed and all
externs should be LIBFFI_DECLARE(type)

eg.

#ifdef(WIN32)
#define  LIBFFI_DECLARE(type)      __declspec(dllexport) type __stdcall
#define  LIBFFI_DECLARE_DATA       __declspec(dllexport)
#else
#define  LIBFFI_DECLARE(type)      __attribute__ ((visibility("default")) type
#define  LIBFFI_DECLARE_DATA       extern
#endif

... or something like that

and then

LIBFFI_DECLARE_DATA ffi_type ffi_type_void;
...
LIBFFI_DECLARE(void) ffi_raw_call ...

etc.

Without dllexport there is not much sense creating dll or windows build
using msvc thought.

> Secondly, I put cc.sh under a Mozilla tri-license, because, well, that's what we use 'round here, and Timothy said any license is fine. But if you'd prefer it under a BSD license for consistency, I don't mind.
>

Shouldn't that match the LICENSE file?
IMHO mixing licenses in the same package might be confusing.


Regards
--
^TM