[Tutor] Compile

[K P]

-------Phoenix-Boundary-07081998-
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable

Thank you for the input. Actually I wanted to know if using other win-based 
compilers was possible. The extra info is much appreciated though, gives me 
something to ponder, and even a little guidance on pursueing this. I've had 
limited success in compiling Python with cygwin, and haven't tried it with 
borland. If I understand correctly, if your compiler can't compile Python, 
don't even try a 'freeze'. Off to the drawing board.
Ken
Hi Max M. Stalnaker, you wrote on 6/2/99 01.24.52 AM:

>
>
>David said it well.  But maybe some more details on the state of the art 
>are acceptable.  As David said, the purpose of 
>freezing is to have a single executable.  This works on Unix, but not 
>quite on Win.  Here are problems as I see them, 
>and I am definitely subject to correction:
>
>1) shared libaries do not freeze.  These are sort-of-dll's and sit in pyd 
>files.  But they could be compiled 
>statically.  Then there are dlls.
>2) winall is probably dependent on some MFC stuff and would need to be 
>rewritten in places to port to an alternative 
>compiler.  Borland is an exception, since they licensed MFC at one point, 
>but no one in the community is providing 
>support for that compiler.
>3) tkinter does not freeze on win platforms
>
>If you were to solve any one of the three items then it would be a 
>significant contribution to the community.  But I 
>think you need msvc++ 6.0 around to solve these problems, even if only as 
>a reference compiler.
>
>The cgipython project does not have win ports yet and item 1 is relevant 
>there.  If you get msvc++ 6.0 and read every 
>scrap of doc you can find, you will eventually be faced with item 1 within 
>the confines of the existing cgipython 
>project.  This would be a reasonable project.  I think your enthusiasm is 
>carrying you in the direction of unreasonable 
>projects.





-------Phoenix-Boundary-07081998---