better way to build libraries..
John-Mark Gurney
gurney_j at resnet.uoregon.edu
Sun Oct 1 18:43:26 PDT 2006
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."
More information about the freebsd-current
mailing list