On 11 Aug 1999 15:11:23 +0200, Lars Gullik Bj°nnes wrote:
> From: Duncan Simpson <[EMAIL PROTECTED]>
>Due to various systems not supporting symlinks (M$ systems are the most
>prominent example) could I suggest a header called something like
>"os_specifics.h" generated by configure by from os_specifics.h.in with
>appropiate substitutions. In particular one of the substitutions would be a
>header that included the os specific stuff. os_specifics.h.in might say
[the careful suggestions clipped]
I don't claim to well understand configure intrinsics, so correct me,
if I'm wrong.
This solution would produce elegant source code, if and only if
configure runs successfully. If not, you are left on you own.
So I would prefer conditional #include's somewhere at the beginning of
relevant source modules (not within function bodies!) that check for
predefined flags like __EMX__, __win32__, __AIX__, __CRAY__, etc.
The disadvantage then is:
This contradicts 'configure' philosophy to never trust system specific
compiler flags, but to check everything in particular (and better twice
than once).
You can hide everything in an 'configured' "os_specifics.h". The
disadvantage then is:
It is difficult to find out, which are precisely all the os_specific
dependencies for the individual source module that you are modifying,
extending. Only if you are warned by those explicit conditional
#includes about system specifics, notorious casual writers of patches
(like me) are always warned about possible non-portability of their
extensions and can see at a glance which portability hacks were
necessary in the past especially for this module. This could
dramatically decrease portability headaches for source-code
maintainers...
I'm certainly not in the position to decide anything, and don't intend
to judge on individual likings based on their personal (often painful)
experiences with one or the other of the possible solutions. All this
should best be discussed in a LyX Portability Design Document.
Greets,
Arnd
