This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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] |
On Tue, Aug 12, 2014 at 11:01:31AM -0700, Roland McGrath wrote: > I think the general approach is sound. I was going to call the main > macro just IS_IN, and I still like that a bit better than IS_IN_MODULE. Thanks for looking at the patches. I don't mind IS_IN for the name. > Rather than the last patch, just make the headers test _LIBC and make it > such that IS_IN (*) is always false #ifndef _LIBC. Likewise, every > place you touch that is "#if defined _LIBC && IS_IN..." can be simplified. OK. > libc-modules.h badly needs comments explaining the scheme (plus the > usual header). I don't really like maintaining that big list and > picking numbers by hand. IMHO it would be better to generate a header > from a simple list of names. Most of the elements of that list can be > culled from shlib-versions files by script, and only the few > non-libraries need to be manually maintained in a list. OK. > I'm not entirely sure that IN_MODULE should be defaulted that way. It > seems more right that we just ensure that it's always defined for every > compilation command we run. Part of doing that (and also generally > cleaner) could be to have a dedicated makefile variable for it, rather > than just adding it to CPPFLAGS and the like. I think we should avoid > any scheme where we wind up producing -Dfoo=blah -Ufoo -Dfoo=bar. OK. > I don't think I fully understand what's going on with MODULE_libs. At > any rate, I don't think that distinction should be made by having the > rhs of -D do arithmetic. With a generate header file, it would be > straightforward to just encode the "category" distinctions by ordering > the numerical values and then test with < and >. It was to distinguish the core libraries. I'll order the modules like you suggest and use < and >. > The #elif chain to define MODULE_NAME is particularly bletcherous. It > would be unnecessary if -DMODULE_NAME=foo is what's passed and > PASTE(MODULE_, MODULE_NAME) is what's used to define IN_MODULE. Of > course, with a generated header you can do it in a variety of ways that > are all equally fine because there is just as little to be maintained by > hand. Ack. I don't remember why I dumped the -DIN_MODULE=foo for -DIN_MODULE=MODULE_foo, but I can revisit that. > What about adding an IS_IN_SHARED(foo) and IS_IN_STATIC(foo) that just > combine IS_IN(foo) with {!,}defined(SHARED) so that we can simplify the > boilerplate for those cases and also get closer to the day when we can > use typo-proof #if for SHARED as well? That sounds good. Siddhesh
Attachment:
pgpI_LmcBMfoB.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |