From owner-freebsd-ports@FreeBSD.ORG Sat Sep 30 17:10:36 2006 Return-Path: X-Original-To: freebsd-ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AFBD16A535 for ; Sat, 30 Sep 2006 17:10:36 +0000 (UTC) (envelope-from alex@foxybanana.com) Received: from ultrasuede.reed.edu (ultrasuede.reed.edu [134.10.2.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BEF343DAA for ; Sat, 30 Sep 2006 17:10:23 +0000 (GMT) (envelope-from alex@foxybanana.com) Received: from Laptop.mine.box (c038h213.dorm.reed.edu [134.10.38.213]) by ultrasuede.reed.edu (8.13.7/8.13.7) with ESMTP id k8UHAJms018375 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Sep 2006 10:10:19 -0700 Received: from localhost (localhost [127.0.0.1]) by Laptop.mine.box (8.13.6/8.13.6) with ESMTP id k8UH9gWG034468 for ; Sat, 30 Sep 2006 10:09:42 -0700 (PDT) (envelope-from alex@Laptop.mine.box) Message-Id: <200609301709.k8UH9gWG034468@Laptop.mine.box> From: Alexander Botero-Lowry To: freebsd-ports@FreeBSD.org Date: Sat, 30 Sep 2006 10:09:42 -0700 Sender: alex@foxybanana.com X-Scanned-By: MIMEDefang 2.57 on 134.10.2.46 Cc: Subject: Re: detect presence of threads support in sqlite3 port X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2006 17:10:36 -0000 > Le Lun 25 sep 06 à 11:21:11 +0200, Alexander Zhuravlev > écrivait : >> So, how can I determine the fact that the port was compiled with such >> option, so I can rise an error in my port or compile it with bundled >> sqlite 3.2 library? >> Any help will be much appreciated. > This is the exact issue that sparked my interest in some kind of OPTIONS dependency/checking mechanism in ports. One of my ports (audio/xmms2) requires that sqlite3 be built threadsafe, and there is no way to detect this at runtime so it would be possible to end up with a nastly corrupted medialib because of this. So the idea would be to store the OPTIONS choices file in the pkgdb as +OPTIONS or something, and then to be able to say NEED_OPTIONS=sqlite3:THREADS or something like that. > sqlite supports pkg-config, so you could try something based upon > > pkg-config --libs sqlite3 | grep '\${PTHREAD_LIBS}' This might not always work since sqlite3's thread safety is if I remember correctly a test to see if threads are using their own contexts or using a global one, and asserting if they try to use a global one. It doesn't really requite pthreads and that is probably just there as a convenience. Alex