Re: better way to build libraries..

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

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."
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"