Re: [Freetype] Re: Summary of ANSI preprocessor trouble..

[Stefan Seefeld]

David Turner wrote:
> 
> Hi Stefan,
> 
> >
> > or you use 'freetype2' on systems that allow it. After all,
> > to write programs that are portable among those with the 8.3 restrictions
> > and the rest, you'll have a whole bunch of other portability issues to care
> > of.
> >
> I really don't see what other portability issues you're referring to. Could
> you give us a few examples of this "whole bunch" ?

I'm sorry, my phrasing was misleading. I wasn't referring to FreeType at all
when speaking about portability issues. But rather, I assume that applications
that are generally written with portability in mind need lots of constructs
(wrappers...) to make that possible. So a simple switch to discriminate between
two paths is certainly only a minor issue.

> My opinion is that your proposal _will_ be a big problem, especially in
> the long term. Do you really think that platform-specific #ifdefs are
> a good thing when using a portable library ?

no, but I seriously doubt that the 8.3 file name restriction will be of any
importance in the future, so I wouldn't base any major decision on that.
In other words, I understand and agree that discriminating based on the 
platform should be avoided. However silly or outdated platforms shouldn't
count.

But then, that's a general decision, depending on your goals. I'm writing
lots of code for the berlin project, and I'm applying all the most recent
C++ techniques. I do know that portability right now is a problem, but I hope
that at the time berlin will be usable, compilers will have catched up...

> What's striking in your proposal is that you didn't complete
> the #elif defined(__linux__) ... line.

:)
Well, I should have written

#ifdef (_8_3_restriction) // which essentially means 'DOS'
...
#else
...
#endif

so all the above 'defined(__linux__)...' falls into the else clause, n'est pas ?

> How would you determine the correct #if / #elif ?
> Who would be in charge of maintaining this monstruosity ?

my point is precisely that there is no monstruosity, the flags for platforms
which need special treatment are few, and become fewer every day.

> And what about:
> 
>   #include <freetype/freetype.h>
> 
>   compile time flags trivially adjustable (either manually or through
>   freetype-config).
> 
> and it buys you portability.. !!

fine.

> Stefan, please understand that unless you provide us with a portable
> proposal that would allow the source code to compile on _any_ platform
> with a pseudo ANSI compiler, there's no way we're going to allow
> special installation cases as the one you're asking for..

I'm sorry, I fully support your proposal, I simply tried to point out
that I wouldn't do any *major* efford to support platforms with the 8.3
restriction. See above.
And the <freetype/freetype.h> thing works well for me, as I don't have
any freetype 1.x in use. Those who have, and who need to use both versions
simultaneously, may get into trouble, though (as a -I flag doesn't associate
a path with a header, i.e. you can't compile a file that needs to include
the freetype headers from both versions. But then, may be I misunderstood
the issue totally...

> Let's say that if nothing new _and_ working hasn't been proposed,
> we revert the source code to the "old" scheme on Friday and release
> 2.0.2

you have my vote.

Regards,        Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: address@hidden

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...