Re: better way to build libraries..

Warner Losh wrote this message on Sun, Oct 01, 2006 at 17:52 -0600:
> In message: <20061001215643.GZ80527_at_funkthat.com>
>             John-Mark Gurney <gurney_j_at_resnet.uoregon.edu> writes:
> : Warner Losh wrote this message on Sun, Oct 01, 2006 at 14:08 -0600:
> : > In message: <20060928231816.GI80527_at_funkthat.com>
> : >             John-Mark Gurney <gurney_j_at_resnet.uoregon.edu> writes:
> : > : Comments?  Improvements?
> : > 
> : > Generally, libraries are considered to be a critical part of the
> : > system.  They often have many different interdependencies.  This is
> : > why we have buildworld: to account for them.  If you make the patches
> : > that you describe, then you break the upgrade path for people with
> : > older systems.
> : 
> : I don't see how adding the ability to do stand alone builds breaks
> : others ability to upgrade their systems through normal means (i.e.
> : buildworld)...
> 
> The odd voo-doo that you posted originally would do exactly this
> because it included /usr/include in the include paths.

No, it did not..  It might of confused you to see /usr/include, but
it was preceeded by ${.OBJDIR}...

> : > You don't need to do a complete buildworld either to get new
> : > libraries.  However, teasing out the parts that you do and don't need
> : 
> : Yes you do, if you don't want to break your existing install by doing
> : a make includes....
> 
> Actually, no you don't.  It is possible to build through the libraries
> stage and then install the libraries.  By possible here, I do mean
> with a little extra programming of Makefile.inc1 to have the right
> packaging of targets.  Hence my comments were phrased the way they
> were.  I've added this Makefile goo in the past for similar targets.

And I still need to build the tool chain and/or many other parts of the
tree, besides doing a simple make in the library directory...

> : > can be a chore.  Maybe we should enhance the build system to be able
> : > to say 'rebuild just the libraries w/o rebuilding the toolchain'.
> : 
> : IMO, even building just the libraries is a bit much...
> 
> Actually, it isn't that bad.  Without building a new toolchain, the
> rebuild of the libraries isn't that bad, even on slower hardware.

If w/ a small patch we can make it even easier for people w/ slow
machines...

> : I would like to integrate this into bsd.lib.mk so that if you use
> : bsd.lib.mk you automaticly get what my patch proposes, but my make-fu
> : is weak...  I will admit this will be a bit redundant for buildworld,
> : but it could be easily turned off in that case...
> 
> I'd definitely like to review this patch.  Your original one gave me a
> great deal of concern.  I'm the person that you'll break if you do
> this wrong, and I've just finished spending an extended period of time
> tweaking things related to cross building (both cross release and
> cross platform).
> 
> If it can be done safely (how you'll do this w/o doing a make
> includes, I'm not sure) and it doesn't break anything else, I'd be all

I do make includes into the obj dir and use that..  (obviously you
need to review is much more closely)...

> for it.  However, if it breaky anything that works now, I'll be less
> supportive.
> 
> On a related note, why not just use the binary upgrade service that
> Colin Percival runs if you don't want to do a source build?

/me isn't sure he can do a piecemeal upgrade of his system w/ it.

Though I will say it did make me think of using it...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."