From owner-freebsd-arch@FreeBSD.ORG Tue May 7 19:29:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5981CF3D for ; Tue, 7 May 2013 19:29:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 19B72DC8 for ; Tue, 7 May 2013 19:29:24 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id jy13so992038veb.9 for ; Tue, 07 May 2013 12:29:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=d8g0uPZKT2TZq5XkBG81CdruQ+YgkSemwjWjB9CqSe8=; b=O3AdIkSui83mKk1bMZvLtFxIbJqYbBQiUY/dnfVqcJOHFKQYwYAKxpzUUzpI+9b2SZ H1U1cV3FOOW4wblVldaIpaZX4z3/CukCbty3aqgaLoYdXhcRcsY1X3xBuj7c8QAVyN2I sNYZrR5ZR4Kh0Y6CINMQV9teF+i66fLGHOpllxdvQjLecpKdgMwTKQjDFzVhF3jkL2mq OcylvQD6VSWlr9lsJcQe05tvd3SJGhLDHOxy+SLmttZ4RJx1Q64+gmVQ9Zix4Y6XRzEv Lvd7MNsCxgI+qMAlZIcnC5+Smwvq303rGxxhPosPACi9dTscZbDBnxpz36nn2h80RTra /lAg== X-Received: by 10.52.98.161 with SMTP id ej1mr1973124vdb.72.1367954963522; Tue, 07 May 2013 12:29:23 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id b7sm23606346veq.7.2013.05.07.12.29.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 12:29:22 -0700 (PDT) Sender: Warner Losh Subject: Re: Building library that depends on another library. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Tue, 7 May 2013 13:29:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130505201436.GJ1374@garage.freebsd.pl> <86r4hkgd04.fsf@nine.des.no> <20130507185005.GB1888@garage.freebsd.pl> To: mdf@FreeBSD.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmXm7YptY5HD7C47HDPodHIOE9I5JzW6kQzQN15icVy9l+hp5vtfaS8PVvGmrZXz/yRIZeA Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:29:24 -0000 On May 7, 2013, at 1:20 PM, mdf@FreeBSD.org wrote: > On Tue, May 7, 2013 at 11:50 AM, Pawel Jakub Dawidek = wrote: >=20 >> On Mon, May 06, 2013 at 08:49:15PM +0200, Dag-Erling Sm=F8rgrav = wrote: >>> Pawel Jakub Dawidek writes: >>>> It looks like to make such dependency work one HAS TO add libnv to >>>> _prebuild_libs in src/Makefile.inc1, which seems wrong. >>>=20 >>> It may seem wrong, but it is correct, cf the following comment in >>> Makefile.inc1: >>>=20 >>> # The list of libraries with dependents (${_prebuild_libs}) and = their >>> # interdependencies (__L) are built automatically by the >>> # ${.CURDIR}/tools/make_libdeps.sh script. >>=20 >> Yes, this also means SUBDIR_ORDERED in lib/Makefile doesn't make = sense. >>=20 >> All in all I really don't like to add libraries to Makefile.inc1, it >> doesn't sound right. I'd like this to be self-contained. For = bsd.prog.mk >> it is enough to specify DPADD/LDADD in program's Makefile instead of >> hacking some central Makefile. >>=20 >> I came up with something like the following. Instead of: >>=20 >> DPADD=3D ${LIBNV} >> LDADD=3D -lnv >> (plus modifying src/Makefile.inc1) >>=20 >> I only add: >>=20 >> LDADD=3D -L${.OBJDIR}/../libnv -lnv >>=20 >> What do people think? >>=20 >=20 > I won't claim any knowledge of various Makefile variables, but at work = we > use this. (I think gcooper is changing this to have the -L in LDFLAGS = so > the LDADD stays pure; I suppose it is better but it's even more = verbose). >=20 > We also use rcorder on our makefiles so they're built in the right = order, > which AFAICT serves the same purpose as DPADD but perhaps less = annoyingly > (no need to define LIBNV somewhere). However, it still requires > over-specification (and a mis-spelling will break it). So for our > libraries, each Makefile should have a # PROIVIDE: line as well as > potentially some # REQUIRE: lines. Using rcorder has the advantage = that it > will detect circular dependencies. >=20 > It would be nice if the existence of an LDADD in the Makefile would > automatically also mean the ordering of build was determined; = DPADD/LDADD > should be in parallel already. And for our use of rcorder, it's = redundant > to have both a REQUIRE line and an LDADD line. But I think quickly = we're > getting past what make(1) can do and into the realms of "build systems = are > hard". DPADD should be sufficient to get the ordering right. Warner=