Re: newlib_cv_ vs libc_cv_ autoconf cache vars prefix
Mike Frysinger <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <YfilH20Jc4Ddwo9D@vapier> |
On 31 Jan 2022 15:17, Corinna Vinschen wrote: > On Jan 28 04:44, Mike Frysinger wrote: > > the newlib/libgloss configure scripts use both libc_cv_ and newlib_cv_ as > > their autoconf cache var prefixes. this really should be just one name. > > i'm inclined to use newlib_cv_ rather than the more generic libc_cv_. any > > preferences or reasons to pick one or the other ? > > > > libgloss also has cache vars. i'm inclined to have it use newlib_cv_ too > > since, as a project, it's carved out the namespace, and doesn't really need > > its own libgloss_cv_ prefix. > > AFAICS, only six libc_cv_* and two newlib_cv_* vars exist at all, and only > two of the libc_cv_* vars are AC_SUBST'ed and show up in the Makefile. > Using the same prefix for all vars, it would be the smaller change to > switch the 2 newlib_cv's to libc_cv. The result would be the same. the reason i'm not a fan of libc_cv is that glibc uses that namespace. if you want to setup a config.site cache for a target that builds glibc & newlib, then it's hard to avoid namespace conflicts. but if we use newlib_cv_, then there's no such collision. -mike
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmH4pR8ACgkQQWM7n+g3 9YEu9Q/+Kev1RHwWEALFdra6ZZ2WtRLg2NnqDvQOFFlasqRxRcf/KydFl47glwQe e1UEI+h7jAlj9JI+Ep15CCmEBd1uZ+5NlgdhYAw34FDb5gFpc2XuMYtt88jwHor/ BWYSxKDU3diaCoRcGB+tBCigKYwP08lSIKuAQde0XcBnwW4u7Ex6yD+jj9b+tMD/ R107vRYsPJiT20yoVz+SghIMzxP224nKJ8xVfJOuYEJ8M7cM0MfyowtMQz2mxhZ6 98fuenr/NqBjBI5gOuQxOZ8CZQ++sOdE08tu1cJleYCXJiFBHVGPS69z2ZYbXdyS CCv51BQmXkVeA4R6jDCtmwO0IKADtZHrf44AZfHL2Tfu3b3Tk3/N/ihjF4AbSeNi rogQKy9eg0ygQa0MR3Awp7S40n2Q/j1dr5v47niStddKJBRZIRzQhQKXvT4JhWuw J1hhnRROqA4c9rNX0KOIFAenT2aZzb+smKfmfYOG3PlI3SJOD3nJjh+MKPWG27eF Hg5Z4Cj3MgiT5rMywVPLoqswaXaWbeeOrsZyHQvfXS5nwzqJQzZ0KcXEDBSwHT1J KgfzAW93LckMDuxXJ5X8hTRms+JN70M8Yto1aOtHT+1roIkpndl/HrSkkb76pF+V 2B6+XBEIZcPJBSYSQ1EGbrU8dx2HfglG6qFSl0Fdd7XnNi/l3NM= =0WnL -----END PGP SIGNATURE-----