Re: FT2 Mac support

[Just van Rossum]

At 8:42 PM +0000 28-02-2000, Werner LEMBERG wrote:
>> config/mac
>> config/mac/FreeTypeLib.prj
>>
>> (this is a CodeWarrior Pro 4 project file. It compiles a static lib
>> called FreeTypeLib into the top level obj/ directory, which can be
>> included by FT clients, such as ftlint and ftview)
>
>I fear this is a binary file, right?

Unfortunately yes. It's a major pain.

>BTW, we will store the files
>with Unix line ending conventions for orthogonality...

For text files, that's fine with me. Either you'll check the file in as
binary, or I provide you with a binhex file, which is pure 7 bit ascii. The
filename will then end in .hqx, and the developer has to unpack it
manually. Seems most easy for you guys.

>> I'm using the files ftconfig.h, ftmodule.h, ftoption.h and
>> ftsystem.c from the config/ansi directory, but I can't judge whether
>> it's neccesary or just preferred to create local copies in the
>> config/mac directory. They work as is, and I don't like to create
>> even more code duplication.
>
>Please duplicate the code.  IMHO it is better to have all
>system-specific files in one subdir.  You can write a small readme
>which explains that the files are just copies from the ansi files.

I *really* dislike this. Most importantly since the ansi stuff *isn't*
platform-specific! At all. It builds & works out of the box on my lovely
toy OS.
I will have to maintain the Mac stuff, so I will have to watch the original
files, and if they change, do the copy again. This situation would be
rather cumbersome for me.

IMHO: code duplication is always a maintaince nightmare, and must be
avoided at all cost.

Polite, but desparate suggestion/plea: create one directory that contains
the following *default* (and portable) files:
  ftconfig.h
  ftmodule.h
  ftoption.h
  ftsystem.c
Platforms or configurations needing extra attention can still provide
customized versions.

I strongly feel the current setup is much more complicated than neccesary.

>> demo/mac/codewarrior -- the place for CW project files:
>
>Is it possible to shorten this dirname to 8 characters?

Sure...

>> demo/mac/ftlint_mac.c -- wrapper around ftlint's main(), emulating
>>                          argc/argv
>> demo/mac/ftview_mac.c -- wrapper around ftview's main(), emulating
>>                          argc/argv
>> demo/mac/macgetargv.c -- support code for emulating argc/argv,
>>                          adapted from MacPython
>> demo/mac/macgetargv.h
>> demo/mac/ftlint.rsrc -- some supporting resources
>> demo/mac/ftview.rsrc -- some supporting resources
>
>Similarly, please try to stay within the 8.3 limit (or at least, 8.x).
>
>Your dir structure looks OK.
>
>> I also have some minor patches to some files in demo/ but I'd first
>>  like to know whether the above is ok for inclusion, so I can submit
>> everything in one go. Hm, I see there are some file and dir names
>> that do not conform to 8.3. Let me know if that's absolutely
>> neccesary to fix (I absolutely agree with Chris Herborth (hi fellow
>> Pythoneer!) that it seems silly to conform to 8.3 for files that
>> will never ever work under DOS.)
>
>Yes, yes, yes, yes.  But :-)

(I really think you guys are driving this too far: eg. the Python language,
which is a *much* larger C program than FT will ever be, works under many
platforms including DOS, yet includes many files with longer file names,
even in directories *needed* for DOS support. But: I'll respect your
conventions so this'll be the last you hear frm me on this subject...)

>I think that you can drop the `mac' postfix/prefix since you put these
>file in a subdir called `mac'.

Erm, for macgetargv.c|h yes, but not for ftlint_mac.c: it includes the
original ftlint.c and my compiler will get confused if I call it the same.
But ok, I'll find shorter names...

Thanks for your feedback,

Just