This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Host name guidelines? (and more)


KJK::Hyperion wrote:
> 
> Hi all. I'm about to add a new host to newlib, and I wonder if there are
> more precise guidelines than "machine-vendor-os". In particular: who's the
> "vendor", exactly? the machine's or the os's? And what characters can be
> used as "os", other than alphanumeric? I'm using newlib to power ReactOS's
> POSIX environment, called POSIX+, and I wonder if a host name of
> "i386-reactos-posix+" would be legal
> 

The name would not be legal.  AFAIK, there are no documented restrictions on using the
'+' character, but regardless, your name doesn't conform to machine-vendor-os.  You might
want to use pc for your manufacturer field which indicates "for an IBM PC compatible
system".  Thus, the name would be: i386-pc-reactos.  This is similar to the existing cygwin
configuration which is i[3456]86-pc-cygwin.

The following is some internal documentation regarding configuration names that may be of some help to you.  I also have some details about your
newlib documentation problem following
this excerpt.

*****************************************************************************************

Configuration Names

The GNU configure system names all systems using a configuration name. All such names used to be triplets (they may now contain four parts in certain
cases), and
the term configuration triplet is still seen. 

Configuration Name Definition

This is a string of the form cpu-manufacturer-operating_system. In some cases, this is extended to a four part form:
cpu-manufacturer-kernel-operating_system. 

When using a configuration name in a configure option, it is normally not necessary to specify an entire name. In particular, the manufacturer field
is often omitted,
leading to strings such as `i386-linux' or `sparc-sunos'. The shell script `config.sub' will translate these shortened strings into the canonical
form. autoconf
will arrange for `config.sub' to be run automatically when it is needed. 

The fields of a configuration name are as follows: 

cpu The type of processor. This is typically something like `i386' or `sparc'. More specific variants are used as well, such as `mipsel' to indicate a
little endian
     MIPS processor. 
manufacturer 
     A somewhat freeform field which indicates the manufacturer of the system. This is often simply `unknown'. Other common strings are `pc' for an
IBM PC
     compatible system, or the name of a workstation vendor, such as `sun'. 
operating_system 
     The name of the operating system which is run on the system. This will be something like `solaris2.5' or `irix6.3'. There is no particular
restriction on the
     version number, and strings like `aix4.1.4.0' are seen. For an embedded system, which has no operating system, this field normally indicates the
type of object
     file format, such as `elf' or `coff'. 
kernel 
     This is used mainly for GNU/Linux. A typical GNU/Linux configuration name is `i586-pc-linux-gnulibc1'. In this case the kernel, `linux', is
separated
     from the operating system, `gnulibc1'. 

The shell script `config.guess' will normally print the correct configuration name for the system on which it is run. It does by running `uname' and
by examining
other characteristics of the system. 

Because `config.guess' can normally determine the configuration name for a machine, it is normally only necessary to specify a configuration name when
building
a cross-compiler or when building using a cross-compiler. 

Using Configuration Names

A configure script will sometimes have to make a decision based on a configuration name. You will need to do this if you have to compile code
differently based on
something which can not be tested using a standard autoconf feature test. 

It is normally better to test for particular features, rather than to test for a particular system. This is because as Unix evolves, different systems
copy features from one
another. Even if you need to determine whether the feature is supported based on a configuration name, you should define a macro which describes the
feature, rather
than defining a macro which describes the particular system you are on. 

Testing for a particular system is normally done using a case statement in `configure.in'. The case statement might look something like the following,
assuming
that `host' is a shell variable holding a canonical configuration name (which will be the case if `configure.in' uses the `AC_CANONICAL_HOST' or
`AC_CANONICAL_SYSTEM' macro). 

case "${host}" in
i[3456]86-*-linux-gnu*) do something ;;
sparc*-sun-solaris2.[56789]*) do something ;;
sparc*-sun-solaris*) do something ;;
mips*-*-elf*) do something ;;
esac

It is particularly important to use `*' after the operating system field, in order to match the version number which will be generated by
`config.guess'. 

In most cases you must be careful to match a range of processor types. For most processor families, a trailing `*' suffices, as in `mips*' above. For
the i386 family,
something along the lines of `i[3456]86' suffices at present. For the m68k family, you will need something like `m68*'. Of course, if you do not need
to match on the
processor, it is simpler to just replace the entire field by a `*', as in `*-*-irix*'. 

*********************************************************************************************

> Another question: I tried to compile the TEX files into HTML, but makeinfo
> complains about missing nodes. Are the docs available in HTML form
> elsewhere? or does anyone know what makeinfo complains about?

I have made some patches to newlib regarding docs.  To make documentation, you issue

  make info

If you want a version of the newlib docs as html, go to your newlib build directory
and issue:  make info MAKEINFO=texi2html

If you don't have the texi2html, you can find it on the web. 
 
   http://www.mathematik.uni-kl.de/~obachman/Texi2html/

-- Jeff J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]