Re: FYI: `Document' qnx (Was: Various systems)

[Akim Demaille]

>>>>> "Pavel" == Pavel Roskin <address@hidden> writes:

Pavel> Hello, Akim!
>> * doc/autoconf.texi (Systemology): New section.  Some about QNX 4.

Pavel> Please undo this patch. We should not document operating
Pavel> systems in the Autoconf manual.

Why not?  I mean, I understand people who would say it does not belong
to the Autoconf Reference Manual, but otoh the Autoconf documentation
aims at providing the user of Autoconf with the answers to the
question she is likely to wonder.

Documenting the shells is one good thing, and I think documenting
systems is good too.  Beginners should be aware there are things named
AIX, HPUX etc. out there.

>> address@hidden is a realtime operating system running on Intel
>> architecture +meant to be scalable from the small embedded systems
>> to hundred +processor super-computer.  It claims to be @sc{posix}
>> certified. More

Pavel> What if QNX is ported to ARM? What if hundreds CPUs become
Pavel> thousands? What if somebody buys QNX? What if it forks?

I don't get your point.

Pavel> In short, autoconf.texi is not the best place to keep this kind
Pavel> of information.

>> +information is available on the @href{www.qnx.com, @sc{qnx} home
>> page}, +including the
>> @href{http://support.qnx.com/support/docs/qnx4/, @sc{qnx}

Pavel> I bet that nobody who needs that URL will search for it in the
Pavel> Autoconf documentation.

Of course they won't: there was no such information before.  Now they
know they're likely to find answers in there.

Pavel> I don't know any autoconf related issues directly related to
Pavel> the OS except maybe the command line lenght limit and
Pavel> executability of shell scripts.

That's not the only point, it's also about knowing where you are
working, not just your tools.  It's about curiosity.

Pavel> Everything else belongs to "Shellology" or "Limitation of usual
Pavel> tools" or to yet to be written "Quirks in system headers" and
Pavel> "Quirks in system libraries".

I very much agree the real content is and will be there.  There must
be listed and classified the failures we know, and certainly not in
Shellology nor Systemology.

Pavel> Finally, it's not the autoconf's way to deal with static
Pavel> OS'es. The autoconf's way is to deal with known problems in
Pavel> possibly unknown combinations :-)

:)