On 2012-04-22 18:06, Garrett Cooper wrote: > On Apr 22, 2012, at 8:51 AM, Dimitry Andric wrote: ... >> However, this will have started failing just very recently, since obrien >> updated to a new file(1) version, and regenerated the config.h file: >> >> http://svnweb.freebsd.org/base/head/lib/libmagic/config.h?r1=208341&r2=234449 > > And this is why NetBSD runs autotools on their tree sources in their build instead of dealing with stale config.h files Well, I wouldn't want to run autoconf during build, firstly because it is horribly slow, and second because the results will be less predictable. Maybe during the bootstrap stage, it would be acceptable. But even then, one of the configure scripts could fail due to too-old system components, and you would be SOL. > which also brings up the bug of what happens if support is available on one architecture, but not the other? Doesn't happen often and I hope it wouldn't happen in sources imported into FreeBSD, but I've seen it happen in the past with various open source projects. Usually, if something is arch-dependent in a config.h file, we simply surround it with #ifdefs. >> Maybe some hackery could be inserted in lib/libmagic/Makefile, so during >> the early stages a 'toned down' config.h file is used. The libmagic >> source has its own getline implementation in contrib/file/getline.c, so >> maybe that could be used instead. > > That seems like a good idea for the time being. > > On the other hand (and this is probably a dumb question), but why is libmagic required in the build-tools stage? Apparently the file(1) build needs a 'mkmagic' tool, which generates .mgc files (the 'compiled' version of magic files). This requirement was originally added in r81845, more than 10 years ago. >> On the other hand, going from 7.x to HEAD via the 'official' route would go like: >> >> - Update 7.x to the latests 7-STABLE >> - Update 7-STABLE to 8-STABLE >> - Update 8-STABLE to 9-STABLE >> - Update 9-STABLE to 10-CURRENT >> >> It is *way* easier to just grab a recent 10-CURRENT snapshot ISO and >> just reinstall. :) > > Ugh. The usecase (that's now broken) is that Jan from Semihalf might have been running CURRENT builds on an older (stable) build machine. I have done this a couple times in the past (but not regularly because I usually follow the above prescribed method or just hop 1-2 major versions). Yes, it might work, but there is no guarantee. I'm not sure if there is enough incentive to change this policy. It would potentially require a lot effort to make it always work. > Other groups I've worked with use the same major version or higher than the running build because of chroot hackery involved in the build process. I wasn't aware of any chroot hackery?Received on Sun Apr 22 2012 - 15:34:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC