Mail Archives: djgpp-workers/1998/02/27/00:06:07
> > The only other ones I can think of that we might need are "dos", "unix", and
> > perhaps "windows".
>
> Yes. I just put in ANSI and POSIX because they're the simplest to do on
> the first pass.
ansi and posix are definite. I think "dos" doesn't make sense; it's
not a compiler. "unix" is too vague, and ansi/posix should cover it.
"windows" is also not a compiler. I'd recommend ansi, posix, and
maybe bc and msc, potentially with a digit after to indicate a version
number (i.e. msc7 or bc3). After all, they're the most popular
platforms people will be interested in being portable to. Maybe add
cygwin?
> > IMHO, functions that don't mention a target should just not mention it.
> [snip]
>
> That conflicts with the proposed tabular format -- all the columns would
> (presumably) exist in each function's documentation, so those not
> explicitly mentioned would implicitly be documented as "no"s. I may have
> misunderstood here though -- we can of course make the table only contain
> columns for mentioned targets.
If a target isn't mentioned, put "?" or "unknown", or omit that column
in the table (after all, we only have one function per table!).
> The "!dos" sounds sensible, yes -- this can be added easily.
Unfortunately, this means that every function needs to list every
compiler we support. Don't know if that's better than assuming
unlisted means unsupported.
> > Yeah, that should be fine, because we can even do:
> >
> > @port-note dos This note about portability to Borland is very very long and
> > @port-note dos doesn't fit on a single line.
>
> That's relying on the way the output is formatted. If @port-note simply
> writes the following:
mkdoc should combine port-note's with the same keyword, in the order
they're given, into a single note.
- Raw text -