Re: better way to build libraries..

On Monday 02 October 2006 15:26, John-Mark Gurney wrote:
> John Baldwin wrote this message on Mon, Oct 02, 2006 at 14:36 -0400:
> > On Monday 02 October 2006 04:24, John-Mark Gurney wrote:
> > > Warner Losh wrote this message on Mon, Oct 02, 2006 at 00:45 -0600:
> > > > In message: <20061002014320.GA80527_at_funkthat.com>
> > > >             John-Mark Gurney <gurney_j_at_resnet.uoregon.edu> writes:
> > > > : I do make includes into the obj dir and use that..  (obviously you
> > > > : need to review is much more closely)...
> > > > 
> > > > I think that we're talking past each other a little, so rather than
> > > > continue down that path, I'll wait for the patch to see what it does
> > > > and make suggested improvements.  Maybe I'll implement the glue code I
> > > > was talking about too, but with a baby due any day now, maybe not. :-)
> > > 
> > > The patch was in the original message...  The one thing that I don't
> > > have the make-fu to do is: a) insert the buildincs before depend  (so
> > > that the psuedo /usr/include is properly depended upon), and b) find
> > > the correct path to tools/install.sh so install doesn't chown/grp the
> > > files...
> > > 
> > > Once a and b are solved, then it can be properly made part of
> > > bsd.lib.mk...  and fully evaluated upon it's merits...
> > > 
> > > btw, my original patch is at:
> > > 
> > 
http://www.freebsd.org/cgi/getmsg.cgi?fetch=722594+0+/usr/local/www/db/text/2006/freebsd-current/20061001.freebsd-current
> > 
> > The sequence ru_at_ mentioned using 'make includes' is already in bsd.*.mk 
and 
> > should be sufficient for what you need.
> 
> And also run w/ a problem that if say, the library build for some reason
> failed, or something else, I end up w/ a broken /usr/include w/o any
> possibility of recovery...  What if I'm building this library to be run
> on another box?  You want me to tar up my local /usr/include, make
> includes, build the library, and then restore the backed up /usr/include?

No, I expect you to only use that for known-safe cases such as a small 
security patch and to use buildworld in all other cases.  'make buildworld 
NO_CLEAN=yes' for this type of update would actually be just about as quick 
as the sequence ru_at_ gave you if you leave your /usr/obj around.

> All just because people object to adding a few lines to bsd.lib.mk that
> will not change behavior that isn't already broken?

I think bsd.*.mk are rather complex as it is.  I don't think extra hacks for a 
few edge cases warrant the extra complexity/obfuscation.

-- 
John Baldwin