[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FT2 Mac support

From: Werner LEMBERG
Subject: Re: FT2 Mac support
Date: Tue, 29 Feb 2000 08:26:07 GMT

> 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.

Really?  In the freetype archive we have a file ending with .hqx, but
it is binary...

> >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.
> 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 see your constraints, and I hear your sobbing :-)

To support your point of view, the GNU Makefile organization must be
changed.  It has to check whether a specific platform provides
specific files.  If not, it has to lookup the default files.  We'll
investigate this, and I'm pretty sure that we can support that.  But
for the moment, please duplicate.

In case someone volunteers to implement these Makefile changes...

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

Maybe.  Patches welcome :-)

> [about 8.3 filenames]
> (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...)

Let me reformulate what I've said: If I unpack the archive under DOS,
I would like to see (a) meaningful names (everywhere), and (b) no
conflicts due to uppercase/lowercase or overlong filenames, causing
ambiguous file names under DOS.  So if the default dir is
`CodeWarrior' under the Mac, stay with this!  `codewarr' under DOS is

I believe that (a) can be fulfilled in most cases with an 8.3 filename

> >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...

To continue what I've written in the last paragraph: What do you think
about mcftlint.c (but please no mcdonald.c) etc.?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]