DragonFly BSD
DragonFly commits List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/share Makefile src/share/doc Makefile src/usr.sbin/lpr Makefile


From: User Joerg <joerg@xxxxxxxxxxxxxxxxx>
Date: Tue, 15 Mar 2005 03:42:27 +0100
Mail-followup-to: commits@crater.dragonflybsd.org

On Mon, Mar 14, 2005 at 06:38:30PM -0800, Chris Pressey wrote:
> On Tue, 15 Mar 2005 00:18:06 +0100
> User Joerg <joerg@xxxxxxxxxxxxxxxxx> wrote:
> 
> > On Mon, Mar 14, 2005 at 09:03:52AM -0800, Chris Pressey wrote:
> > > I'm OK with this (I actually like the idea of pregenerating stuff in
> > > CVS in general.)
> > 
> > I'm not a fan of commiting pregenereated stuff into the CVS repo.
> > Actually I want to continue removing prebuild stuff like the
> > various device tables and create them on the fly.
> 
> Yeah, I understand.  I was thinking of two things in particular:
> 
> - having pre-built .depend files would shave off some buildworld time,
>   but yes, it would be more of a hassle when committing stuff, to make
>   sure the .depend files are up to date.
>   (Alternatively, maybe make(1) itself could be trained to build the
>    .depend files itself when they don't exist...?  Any thoughts, Max?)

Prebuilt .depend files add another bunch of problems for maintainance.
They have been abounded for a reason :)

> - the monster known as bin/sh.  It would be generous to describe it as
>   being written in C; it's written in some ad-hoc programming language
>   which is translated into C by its build process :)  Again, maybe this
>   could be improved upon by some means besides just committing a
>   pregenerated version into the repo, but, as it stands, it is one very
>   intimidating piece of software, and I don't really like that, since it
>   encourages a sort of "don't touch it, it might break" attitude for
>   maintenance.

bin/sh is not that big of a problem. The general overhead of make and
esp. the inability to express things like high-order rules is annoying
at best. But this discussion had been done before, no need to repeat.

> > > I'm also OK with an (e.g.) "installextradocs" target, to be run
> > > after "installworld", which generates and installs these docs.
> > 
> > That's something I don't object at all :) Fell free to add such a
> > target to etc/Makefile. I think that's the location making the most
> > sense. Well, actually it should be "buildextradocs" and
> > "installextradocs" :)
> 
> Right.  I may or may not get around to this any time soon, since I don't
> feel terribly strongly about it, but at least it's an open option.

So we agree on that :)

Joerg



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]