This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH] Automated the generation of the __NEWLIB__, __NEWLIB_MINOR__ and __NEWLIB_PATCHLEVEL__ macros.
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Pieter du Preez <pdupreez at gmail dot com>
- Cc: newlib at sourceware dot org
- Date: Fri, 29 Jan 2016 10:11:25 -0500 (EST)
- Subject: Re: [PATCH] Automated the generation of the __NEWLIB__, __NEWLIB_MINOR__ and __NEWLIB_PATCHLEVEL__ macros.
- Authentication-results: sourceware.org; auth=none
- References: <20160125201938 dot GA19917 at bling> <20160128103806 dot GD10851 at calimero dot vinschen dot de> <2044933968 dot 16515818 dot 1453987626889 dot JavaMail dot zimbra at redhat dot com> <20160129142013 dot GA28886 at bling>
----- Original Message -----
> On Thu, Jan 28, 2016 at 08:27:06AM -0500, Jeff Johnston wrote:
> > I am in Belgium this week. Most of the patch is fine, however, there is a
> > problem caused
> > because <sys/features.h> doesn't include <newlib.h> and existing code could
> > be expecting
> > <sys/features.h> to bring in the definition of the macros.
> Thanks Jeff, you're right. I wrongly assumed that consumers will
> _always_ include the generated newlib.h.
> Even though newlib.h gets included by _ansi.h, which gets included
> almost everywhere, it is _not_ included from all the files that
> libc/include/sys/features.h is being included from. If a consumer of
> newlib includes any of the following, libc/include/sys/features.h gets
> included, but not newlib.h:
> I can easily adapt the patch, but of course there's at least 3 ways to do
> this (note: all solutions require the re-definition guarding,
> mentioned above):
> 1. Simply leave libc/include/sys/features.h as is, and live with the
> burden of manually updating the version macros in it, every time the
> version changes.
> #ifndef __NEWLIB_H__
> #define __NEWLIB__ 2
> #define __NEWLIB_MINOR__ 2
> #define __NEWLIB_PATCHLEVEL__ 0
> 2. We generate a newlib_version.h at the same level as newlib.h
> is, and include newlib_version.h in both newlib.h and
This idea could be modified to do something like glibc does for bringing in particular macros
from a header file (e.g. __need_size_t to bring in just size_t from stddef.h). Thus, you
set __need_version_macros and include newlib.h in <sys/features.h> and modify newlib.h.in
accordingly. This restores the current behaviour. What do you think?
> 3. Remove the existing 2 definitions from libc/include/sys/features.h
> and include newlib.h in the 18 header files, mentioned at the start of
> this email.
> Although the 2nd and 3rd solution requires a bit more work, it frees the
> maintainer(s) of newlib from the burden to update the version in 2
> different places, every time the version changes.
> Please let me know which one you'd prefer. Other suggestions are also
> BTW, I'm voting for solution 3.
> Pieter du Preez