From owner-freebsd-ports@FreeBSD.ORG Fri Apr 1 03:55:24 2011 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD082106564A for ; Fri, 1 Apr 2011 03:55:23 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 74DE38FC0A for ; Fri, 1 Apr 2011 03:55:23 +0000 (UTC) Received: by wyf23 with SMTP id 23so3116396wyf.13 for ; Thu, 31 Mar 2011 20:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=xR+ao2xJPOykmiMUcZ4qfLN3oxZdKTxZCGiCJfjkOLI=; b=AiZ6ytP62dXa/SzBJDUixAIrt1EdPV8+S5r9Yj6UEGA8z3aiyW+ueAsSP2xyAVypUp gDfdO28P738KV0J4x/kQ/N/w6Hd3pdreh49CSEKerOh/fb39GGcc85fcOKGKTBFQR9Sr aMrZKohTMLT0mq03MA35thbVDtSyQiRY7VogM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eitanadler.com; s=0xdeadbeef; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=hUihUsSd6Ax/ag4VNUNQPbAgZROMJVnRYJNUMETKNLFq7lyLwd0vtgil9nSkXiLX5n m2iyjGOQxG8vd+/MBfvMNxuuDg3JtwLjllsEwqu11tPa4HsAAPcNEi+cIyfvPpCefhwB YHAtfRNTOZ6JU/XWmrjDtZ2Q04k8AMwrBZhsA= Received: by 10.227.91.77 with SMTP id l13mr3555691wbm.44.1301630122113; Thu, 31 Mar 2011 20:55:22 -0700 (PDT) MIME-Version: 1.0 Sender: lists@eitanadler.com Received: by 10.227.153.197 with HTTP; Thu, 31 Mar 2011 20:55:02 -0700 (PDT) From: Eitan Adler Date: Thu, 31 Mar 2011 23:55:02 -0400 X-Google-Sender-Auth: 8PmbqpiLTXyL4lpLGdmleLXP78g Message-ID: To: FreeBSD Ports Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Removing Cruft from the ports tree 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: Fri, 01 Apr 2011 03:55:24 -0000 Hi, I=E2=80=99m been working recently on a series of PRs that called =E2=80= =9CReaper of the Dead=E2=80=9D PRs. I have been going through the various build files= we have (for source, docs, and especially ports) and attempting to remove dead code, old cruft, and unneeded checks. Some examples include ports/155543, ports/155511, ports/154395, conf/155737, and conf/155738. My goal has been twofold: making it easier to understand what is going on, and speeding up the process without requiring significant change. One of the features that has given us the most trouble has been the options framework for ports. We automatically test ports using the default options, but we are unable to perform automated using every combination of options. A port with just four options has sixteen possible configurations, and some ports have more than that. Even supporting one option might double the number of things to test. However some ports rely on specific configurations of options of other ports. In order to deal with this mess we have come up with a hack: slave ports. We have entire ports that are designed just to change the default options for other ports. This requires a non-trivial amount of code on the bsd.*.mk files to support. Automated configuration is not the only thing that has caused us trouble in the past. We routinely have to do deal with questions from inexperienced users on questions@ and ports@ details problems with non-standard configurations. Many times the solution to a ports related problem is flipping a bit in the options file. I propose removing the options systems entirely. While it does serve a small purpose of allowing customization for some end users, I believe the flaws outweigh the benefits. Removing the options framework would enable us to remove over 500 lines of expensive code from the ports system. Not only that but because maintainers would be able to choose the best possible configuration for the their port users would no longer have to mess around. While I understand there might some minor part of the community that has a sentimental attachment to the blue-on-gray-on-blue configuration, and still others want to prematurely optimize, a simple workaround could be implemented. We can allow users to add their own ./configure arguments to the makefile. This serves the needs of the community while allowing us to deal with a simpler and more reliable ports system. Feel free to express your thoughts here. I would like to get this hashed out now so the process could occur on a later date(1). --=20 Eitan Adler