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]

Re: [siddhesh/is_in_module] Fix SHLIB_COMPAT -Wundef warning


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]