Date: Mon, 04 Sep 2000 00:20:29 -0600 From: Warner Losh <imp@village.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Local changes to the contrib tree(s) Message-ID: <200009040620.AAA22097@harmony.village.org> In-Reply-To: Your message of "Mon, 04 Sep 2000 17:07:32 %2B1100." <00Sep4.170723est.115265@border.alcanet.com.au> References: <00Sep4.170723est.115265@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <00Sep4.170723est.115265@border.alcanet.com.au> Peter Jeremy writes: : 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? I find it esthetically displeasing. It would be less ugly to commit it to /usr/src/usr.bin/utility/somefile.c and control things with Makefile .PATH. This way it is easy to generate patches for the maintainer and we don't have to maintain patch files which is a major major pita. This is similar to how we do added files. These files can come and go w/o any CVS difficulties. -D still works. branches still work. The only cost is a slight bit of potential confusion with having two copies in the tree. Sure, this file would live in the Attic when it is deleted, but we have lots of files there already. Hmmm, people importing new versions of the package would need to merge into this file too, which is also a disadvantage. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009040620.AAA22097>