From owner-freebsd-arch Sun Sep 3 23: 7:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id 8A1DD37B422 for ; Sun, 3 Sep 2000 23:07:50 -0700 (PDT) Received: by border.alcanet.com.au id <115265>; Mon, 4 Sep 2000 17:07:23 +1000 Date: Mon, 04 Sep 2000 17:07:32 +1100 From: Peter Jeremy Subject: Local changes to the contrib tree(s) To: freebsd-arch@freebsd.org Message-Id: <00Sep4.170723est.115265@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This is a meta-arch posting discussing the architecture of the FreeBSD build process, rather than the architecture of FreeBSD] One problem with CVS is that once a file is removed from the vendor branch, it can never return to the vendor branch, requiring manual conflict resolution for every future upgrade. As a result of this, there's strong pressure not to take files off the vendor branch. Instead, patches are submitted to the relevant author and the fix will be integrated with the next release. I would like to propose something closer to the ports build process - the vendor files are never touched, instead a series of patches are applied to the original sources before compilation. This way, temporary local changes can be easily applied and removed. As an example, given: /usr/src/contrib/utility/somefile.c /usr/src/usr.bin/utility/somefile.pch the make would start by applying somefile.pch to somefile.c, creating /usr/obj/usr/src/usr.bin/utility/somefile.c, which is then compiled. The downside is that maintaining the patches requires more effort than just editing the files in place, though a make target could be created to create the .pch file from the patched source. What do other people think of this? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message