[17095] in Kerberos_V5_Development
Re: [RFC][PATCH] krb5 => libverto main loop
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Aug 22 18:33:07 2011
From: Greg Hudson <ghudson@mit.edu>
To: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <493C57AC-CFA4-44CD-BBF3-B4C6794C6E07@mit.edu>
Date: Mon, 22 Aug 2011 18:33:02 -0400
Message-ID: <1314052382.28454.14.camel@t410>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Sat, 2011-08-20 at 15:48 -0400, Ken Raeburn wrote:
> I've always liked that (except for the com_err mess), but I've always
> expected that eventually the external dependencies would have to
> become more advanced. It took us quite a while to start demanding C89
> support, and after more than a decade we don't require C99.
MSVC doesn't implement very much of C99, so requiring C99 would mean
switching to MinGW for the core Windows build. I don't know exactly
what the implications of that are since we generate DLLs and wouldn't
want to require DLL consumers to use MinGW as well.
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs suggests that at a minimum
we'd need to use a Microsoft tool to generate a lib file usable by MSVC.
If that's the end of it then it might be okay (although requiring the MS
SDK in addition to MinGW sounds a little annoying), but converting would
still be a lot of work.
> Maybe it's time to add more dependencies or at least stop supporting
> some much older configurations (lack of threads, lack of IPv6, ancient
> Tcl versions for tests, etc).
It's probably time to deconditionalize the threading and IPv6 code, yes.
(As for the issue at hand, I will take charge of doing what we
reasonably can to minimize the pain of relying on an external event
loop, but I'm not sure exactly what that is yet.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
