Date: Fri, 29 Sep 2006 03:12:46 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: better way to build libraries.. Message-ID: <20060929101245.GP80527@funkthat.com> In-Reply-To: <20060929094936.GH86237@rambler-co.ru> References: <20060928231816.GI80527@funkthat.com> <20060929082713.GD86237@rambler-co.ru> <20060929083959.GG86237@rambler-co.ru> <20060929092233.GO80527@funkthat.com> <20060929094936.GH86237@rambler-co.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Ermilov wrote this message on Fri, Sep 29, 2006 at 13:49 +0400:
> On Fri, Sep 29, 2006 at 02:22:33AM -0700, John-Mark Gurney wrote:
> > are you saying that
> > we should go ahead and remove all the -I../../sys in places like
> > pciconf because building standalone isn't supported?
> >
> Yes, we've been doing this (removing them) for years now.
> pciconf is special -- it needs this because we don't install
> sys/dev/pci/pcireg.h into /usr/include.
Interesting, other people seem to think that they are suppose to stay
around... I'll remeber to remove them when I see them from now on...
> > My point is
> > that either we continue to attempt to support building things stand
> > alone, or we don't even pretend we attempt to...
> >
> Removing -I's doesn't generally affect standalone building, but
> it does affect stanalone upgrading. That's the difference. If
> your sources match your installed bits, you can still chdir into
If my sources matched my installed bits, why'd I be building/upgrading
in the first place? :)
> a directory and type "make", and it will generally be built.
> Yes, we should stop pretending we support standalone upgrades --
> because in this case you need to handle it properly: track
> dependencies, build and install dependencies (other headers and
> libraries, this library's headers if this is a library) in the
> correct order, etc. Some of them depend on the src.conf (or
> make.conf) options, there's a lot to track.
not if you know only that one library changed... and for most security
upgrades, it should be one or two components that are affected, and so
is simple enough to manage the dependencies...
> > Everyone points that oh, buildworld does that prefectly fine, but no
> > one wants to expand support of being able to build FreeBSD piecemeal
> > on a system....
> >
> I think you misunderstand the difference between upgrades and
> standalone builds.
I understand the difference, I just think that standalone means not
requiring /usr/include to be populated w/ files from the component you
are building...
I wonder how many people's build and commit errors would have been fixed
by using a method like this... It built for me./Darn, I forgot to make
includes so I wasn't building w/ the proper headers.
Though I agree buildworld is good for testing, people don't have
infinately fast disks and cpu's, and buildworld takes time. I would
be very surprised if even 50% of commits are done w/ a proper buildworld
let alone a universe before committing...
It should work exactly how you build OpenSSL and other libraries that
aren't part of FreeBSD... you build them and they automagicly use the
includes that come w/ the package, and you install them all at once...
Yes, they usually depend upon other headers that are part of the
system, but as you said, dependencies are hard... If you're doing it
by hand, you can track the dependencies by hand..
> > Take my 5.4-R box... I was unable to build libcrypto due to not
> > having done a make includes... I could do a make includes, but then
> > if either a) I forget to make and install the library, or b) the
> > library fails to build, I now have a broken install... It is
> > much better to do a build the library, then install both the new
> > library and includes...
> >
> This approach is doomed. You were lucky (or not, haven't actually
> checked) that this particular upgrade didn't update .h files.
not.. it modified a few of the .h files... I wouldn't have known
of this issue if it had left the .h files alone..
> Because if it did, you'd still be forced to rebuild other bits that
> use an updated header -- other crypto libraries, other stuff
> that uses crypto, statically linked programs if there are any.
If we did update the .h file, and it did break the API, doesn't that
mean we need to have bumped the major number??
> Well, if you absolutely want to, you could installed the headers
> into a temporary location using DESTDIR,
>
> make includes DESTDIR=/foo
>
> then rebuilt the library with DEBUG_FLAGS=-I/foo. In any case,
> even this broken approach doesn't require modifications to
> makefiles.
Which is exactly what my patch did... though your method requires
root, which it shouldn't... (IMO this way is not broken, the the proper
way to build a library)...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060929101245.GP80527>