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."Received on Fri Sep 29 2006 - 08:12:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC