Re: [pywin32-checkins] pywin32 setup_win32all_core.py,1.5,1.6

[Thomas H. <th...@py...>]

"Mark Hammond" <mha...@sk...> writes:

>> But even before this, I get compilation errors with mingw. An example:
>>   win32/src/PyACL.cpp: In function `BOOL _ReorderACL(_ACL*)':
>>   win32/src/PyACL.cpp:89: `ACCESS_DENIED_OBJECT_ACE_TYPE'
>> undeclared (first use
>>      this function)
>>   win32/src/PyACL.cpp:89: (Each undeclared identifier is
>> reported only once for
>>      each function it appears in.)
>>   error: command 'gcc' failed with exit status 1
>
> I've been making lots of changes for that mainwin toolkit recently, and
> didn't strike that one.
>
>>
>> If someone tells me how this can be fixed I'll happy to also bring
>> this up to date for mingw.
>
> A quick grep shows:
>
> WinNT.h:#define ACCESS_DENIED_OBJECT_ACE_TYPE           (0x6)
>
> So I suggest a simple:
> #ifndef .... // mingw
> #define ....
>
> If nothing else pops up.  I should install mingw, but it is worth noting
> that we already require some unknown semi-recent version of the "platform
> sdk" rather than a vanilla MSVC6.  However, Roger Upole did most of recent
> the security stuff, but also himself struck a "platform sdk" version problem
> trying to build the recent shell changes, so it seems unlikely it is simply
> that.  So buggered if I know :)

Well, I have the newest Platform SDK installed (Feb 2003, IIRC).  But I
assume mingw doesn't use it (at least not without some hints from me).
I did try to use the VC6 header files from mingw, but this made things
worse (and was probably a bad idea).

FWIW, I do not care for mingw myself ('cause I see no reason to use it),
and I definitely do *not* want to port win32all to mingw <wink>.  For
now, I would only like to make sure that the setup script works with
mingw, but only if the source is ready for it - but this can also be
done by someone else.

>> Whether they work or not - I cannot currently tell.
>
> Woo hoo - check it in :)

Already done (as you noted in another email).  You can expect a further
checkin today, it seems I can build *and install* the win32all subset I
use myself.  This includes the basic win32 stuff, services, eventlog,
but no PythonWin, scintally, ax, or stuff like that.

The file locations are different from the win32all standard, but I don't
think this hurts.  Except, maybe, for pywintypes and pythoncom, which
should be in sysdir.  But this can be done later, maybe with the
post-install script of bdist_wininst.
>
> No worries - feel free to just hack away on this!
>
> And while I am writing a mail - should I check in the "dicts.dat" change to
> py2exe?  For some reason, the hacks etc and bother I went to, to make it
> work in the first place, bother me enough to want to remove it now!

I have already checked it in, maybe you should double check to make
sure it is what you need.

Thomas