From patchwork Mon May 15 19:39:57 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Huemer X-Patchwork-Id: 762688 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.osmocom.org (lists.osmocom.org [IPv6:2a01:4f8:191:444b::2:7]) by ozlabs.org (Postfix) with ESMTP id 3wRWLQ2btcz9s1h for ; Tue, 16 May 2017 05:46:54 +1000 (AEST) Received: from lists.osmocom.org (lists.osmocom.org [144.76.43.76]) by lists.osmocom.org (Postfix) with ESMTP id B98E5348FC; Mon, 15 May 2017 19:46:50 +0000 (UTC) Authentication-Results: lists.osmocom.org; dmarc=none header.from=xx.vu X-Original-To: openbsc@lists.osmocom.org Delivered-To: openbsc@lists.osmocom.org X-Greylist: delayed 411 seconds by postgrey-1.34 at lists.osmocom.org; Mon, 15 May 2017 19:46:49 UTC Authentication-Results: lists.osmocom.org; dmarc=none header.from=xx.vu Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=81.7.3.51; helo=yade.chaostreff.at; envelope-from=alexander.huemer@xx.vu; receiver=openbsc@lists.osmocom.org Received: from yade.chaostreff.at (yade.chaostreff.at [81.7.3.51]) by lists.osmocom.org (Postfix) with ESMTP id 57BD2348E6 for ; Mon, 15 May 2017 19:46:48 +0000 (UTC) Received: by yade.chaostreff.at (Postfix, from userid 1001) id 568AF100A52; Mon, 15 May 2017 21:39:57 +0200 (CEST) Date: Mon, 15 May 2017 21:39:57 +0200 From: Alexander Huemer To: openbsc mailinglist Subject: Proposal: Usage of stow in jenkins build scripts Message-ID: <20170515193957.GA2859@yade.chaostreff.at> Mail-Followup-To: openbsc mailinglist MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: openbsc@lists.osmocom.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of OpenBSC, OsmoBSC, OsmoNITB, OsmoCSCN" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openbsc-bounces@lists.osmocom.org Sender: "OpenBSC" Hi, The osmocom software that I do not install via apt but build myself gets installed in $HOME/usr and I do things like: export PATH="${PATH}:${HOME}/usr/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib" export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig MANPATH="${MANPATH}:${HOME}/usr/man" Therefore I don't have to install to a destination outside my home directory which in turn means I can avoid some sudo calls. But that actually does not matter so much, you can mentally substitute $HOME with '/' and append '/local' in the following if you want. I don't install to $HOME/usr directly but use stow for 'managing' the installations, so an installation goes like this: $ mkdir -p $HOME/src/telco/osmo/libosmo-abis $ cd $HOME/src/telco/osmo/libosmo-abis $ git clone git://git.osmocom.org/libosmo-abis $ autoreconf -i $ ./configure --prefix=$HOME/usr/stow/libosmo-abis $ make $ make install $ STOW_DIR=$HOME/usr/stow stow libosmo-abis This has two advantages: * Good visibility of what is installed by a package. $ tree $HOME/usr/stow/libosmocore * Possibility of uninstalling a package even if the Makefile is not present. For me those two advantages outweigh the small additional effort of using stow. Because of that workflow I sometimes run into situations in which make runs fail because either header files are not found during compilation or libraries are not found during linking. The reason is that autotools variables pointing to pkgconfig supplied directories point to a destination under the prefix path with which configure was called. If a dependency was not mentioned in a Makefile.am the required files are not found because the other dependencies are in other directories. For a system on which the osmocom-own dependency libs are installed in distinct directories, current openbsc master HEAD requires the attached patch for a build to succeed. I admit that in most situations the dependencies are installed in the same directory so this does not matter, but it is still a small bug. Therefore I propose to modify the jenkins build scripts so that they use distinct, stow managed directories for the dependencies. That should help to detect oversights, although admittedly developers would have to adapt their workflows to use stow as well in their daily hacking. Otherwise an oversight would be detected by jenkings and not locally which in turn would require additional cleanup commits which is not so nice. What is your gut feeling? Does the increased correctness of Makefiles.am contents justify the (IMO rather small) additional effort of using stow? Kind regards, -Alex From e9fc0ed9c7b6c1acc70714f703983708f5d8a1ee Mon Sep 17 00:00:00 2001 From: Alexander Huemer Date: Mon, 15 May 2017 20:42:47 +0200 Subject: [PATCH] Add missing _CFLAGS and _LIBS These missing pieces go unnoticed if dependencies are not installed in distinct directories. Change-Id: If8d57b72f63d79cc0d8efba7466c6ec177207cbb --- openbsc/src/utils/Makefile.am | 3 +++ openbsc/tests/sndcp_xid/Makefile.am | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/openbsc/src/utils/Makefile.am b/openbsc/src/utils/Makefile.am index 9c3837a36..26494e13d 100644 --- a/openbsc/src/utils/Makefile.am +++ b/openbsc/src/utils/Makefile.am @@ -109,6 +109,7 @@ osmo_meas_pcap2db_LDADD = \ osmo_meas_pcap2db_CFLAGS = \ $(LIBOSMOCORE_CFLAGS) \ $(LIBOSMOGSM_CFLAGS) \ + $(LIBOSMOABIS_CFLAGS) \ $(NULL) osmo_meas_udp2db_SOURCES = \ @@ -125,6 +126,7 @@ osmo_meas_udp2db_LDADD = \ osmo_meas_udp2db_CFLAGS = \ $(LIBOSMOCORE_CFLAGS) \ $(LIBOSMOGSM_CFLAGS) \ + $(LIBOSMOABIS_CFLAGS) \ $(NULL) meas_json_SOURCES = \ @@ -140,5 +142,6 @@ meas_json_LDADD = \ meas_json_CFLAGS = \ $(LIBOSMOCORE_CFLAGS) \ $(LIBOSMOGSM_CFLAGS) \ + $(LIBOSMOABIS_CFLAGS) \ $(NULL) diff --git a/openbsc/tests/sndcp_xid/Makefile.am b/openbsc/tests/sndcp_xid/Makefile.am index 99b9d1a4f..d09c41b28 100644 --- a/openbsc/tests/sndcp_xid/Makefile.am +++ b/openbsc/tests/sndcp_xid/Makefile.am @@ -15,6 +15,7 @@ sndcp_xid_test_LDADD = \ $(LIBOSMOGB_LIBS) \ $(LIBCARES_LIBS) \ $(LIBCRYPTO_LIBS) \ - -lgtp -lrt -lm + $(LIBGTP_LIBS) \ + -lrt -lm -- 2.11.0