Subject: Re: libm and i387-specific routines
To: Nathaniel D. Daw <daw@panix.com>
From: Erik Bertelsen <erik@sockdev.uni-c.dk>
List: tech-install
Date: 01/21/1997 19:25:47
On 21 Jan 1997, Nathaniel D. Daw wrote:

.. Mike Long <mike.long@analog.com> writes:
.. 
.. [my complaining about having to edit /usr/src/lib/libm/Makefile to
.. take advantage of my FPU deleted]
.. 
.. > AFAIK, the problem isn't that i386s will run code using the full range
.. > of FPU instructions slowly, but that they won't run it at all.  The
.. > reason is that the FPU emulator is lacking.
.. 
.. In spite of this, I would argue that technology marches on and the
.. default at this point should be to assume an FPU. I just hate having
.. to remember to uncomment that Makefile section every time I build the
.. world. And it always makes me wonder what performance I'm losing
.. elsewhere by not making undocumented edits to randomly placed source
.. files elsewhere. If these kind of decisions come up elsewhere in
.. userland, perhaps there should be a centralized config-style process
.. for configuring your userland build as well as your kernel. Ideas?
.. 
Now that we have the possibility for using /etc/mk.conf, we may do some-
thing like the following:

Allow definition of several Makefile variables that that act like
e.g. the current NOMAN, NOPROFILE, e.g. they control parts of the
build process.

Examples:

LIB_LIBM_USEFPU=yes
USR_SBIN_TCPDUMP_SUPPORTFDDI=yes
GNU_LIBEXEC_OMIT_UUCP=yes

Name these variables to indicate where they are used. Use them in a
way where no value definition gives the current behaviour. The examples
above may not be authoritative, but they do illustrate my idea.

I have cc'ed tech-install which may be appropriate for further
discussion.

regards
Erik Bertelsen