From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH XEN v3 01/22] tools/Rules.mk: Properly handle libraries with recursive dependencies. Date: Thu, 8 Oct 2015 12:38:09 +0100 Message-ID: <1444304289.1410.163.camel@citrix.com> References: <1444226543.1410.53.camel@citrix.com> <1444227341-875-1-git-send-email-ian.campbell@citrix.com> <22038.20914.502555.6352@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <22038.20914.502555.6352@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: wei.liu2@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2015-10-08 at 12:21 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH XEN v3 01/22] tools/Rules.mk: Properly > handle libraries with recursive dependencies."): > > In tree libraries which link against other in tree libraries in a way > > which is opaque to their callers need special handling, specifically > > correct use of -Wl,-rpath-link for the recusively used libraries. > > > > Currently this is rather simple, but up coming changes are going to > > introduce transitive dependencies more than 1 step deep. > > > > Introduce a SHDEPS idiom to contain all the recursive deps for a > > library and include those in both LDLIBS (for linking) and SHLIB (for > > recursive uses). > > > > Try and document the whole thing. > ... > > Thanks. > > > +# Compiling and linking against in tree libraries. > > +# > > +# In order to compile and link against an in-tree library various > > +# cpp/compiler/linker options are required. > > +# > > +# For example consider a library "libfoo" which itself uses two other > > +# libraries: > > +# libbar - whose use is entirely internal to libfoo and not exposed > > +# to users of libfoo at all. > > +# libbaz - whose use is entirely internal to libfoo but libfoo's > > +# public headers include libbaz's one or more of libbaz's > > +# public headers. Users of libfoo are therefore transitively > > +# using libbaz's header but not linking against libbaz. > > The first sentence seems slightly mangled. Ah yes. I think I meant: +# libbaz - whose use is entirely internal to libfoo but libfoo's +# public headers include one or more of libbaz's +# public headers. Users of libfoo are therefore transitively +# using libbaz's header but not linking against libbaz. (dropping a stray "libbaz's" from the middle) > You seem to have reinvented half of pkg-config. But it's small, so, > with the docs fix, > > Acked-by: Ian Jackson Thanks. Probably we should look at shipping pkg-config files for these libraries, for the benefit of third parties. I'm not sure how well pkg-config can be made to work for in-tree users. I suppose it can be directed to examine some $PATH thing for .pc files, but I'm less sure about having it ignore system installed versions of things (i.e. older versions). Ian.