Subject: Re: overriding MAKEDEV.tmpl
To: Greg Troxel <firstname.lastname@example.org>
From: Brett Lymn <email@example.com>
Date: 12/26/2007 01:35:04
On Sun, Dec 23, 2007 at 10:27:00AM -0500, Greg Troxel wrote:
> I meant specifically the override-so-not-modified approach.
There seem to be a few instances in that Makefile already.
> In that case, independent from any considerations of what to commit
> back, you probably ought to be tracking your own sources in a VCS with
> NetBSD on vendor branch.
Yes, I do that already but I thought this one may have a more generic
use. One of the good things about this approach is that you can have
multiple projects with differing requirements - something that is very
difficult to do at the moment without separate source trees.
> If there is already the notion of overriding files, program lists,
> etc. for making CDROMs (rather than having modifed files), then this
> seems fine. I meant only to suggest that if this is the first instance
> of this flavor then stepping back to think of other approaches might be
> useful, because it feels like solving a problem by adding hooks when
> really what you are doing is modifying the sources for a custom build.
> The hooks can only go so far, and actual modifications are a much more
> general solution.
Well, that is why I thought I would ask for a sanity check here... if
I thought it was indispensible I would have just committed it :)
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited. If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility. It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to