Re: svn commit: r228143 - in head: . share/mk tools/build/options
On 12/20/11 9:06 PM, Doug Barton wrote: On 12/20/2011 06:08, John Baldwin wrote: The defaults for src.conf should be for the common case Agreed. The problem we seem to be missing here is that developers are not even statistically significant in measuring the common case. Users using freebsd-update don't care (they aren't building the world). Having the profiled libraries installed does not negatively impact users. However, it requires extra effort for application developers (not necessarily just kernel developers) who want to profile the applications they are working on. I think application developers is a larger portion of our userbase than you are allowing for. However, that notwithstanding, profiled libraries are not actually costing users anything (except for ones who build world by hand), but removing them from default installs does remove functionality. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Wed, Dec 21, 2011 at 10:50:42AM -0800, Doug Barton wrote: On 12/20/2011 9:59 PM, Steve Kargl wrote: On Tue, Dec 20, 2011 at 09:30:10PM -0800, Garrett Cooper wrote: On Tue, Dec 20, 2011 at 8:55 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Tue, Dec 20, 2011 at 06:45:07PM -0800, Doug Barton wrote: On 12/20/2011 18:29, Ben Kaduk wrote: 2011/12/20 Doug Barton do...@freebsd.org: On 12/20/2011 06:08, John Baldwin wrote: The defaults for src.conf should be for the common case Agreed. The problem we seem to be missing here is that developers are not even statistically significant in measuring the common case. The common case of what, though? ?People using src.conf, or people rebuilding world, or just people using FreeBSD? The latter of course. The overwhelming majority of FreeBSD users will never use profiled libs, and in fact don't even know what they are. It's just useless space being taken up on every install. The defaults should be sensible for our users. OK, Doug, we get it! You don't like profiled libraries. You don't use them, and by extension the 'common user' does not use them. It's not about me. :) (And by extension, it's not about you either.) i Thi point that I was trying to drive home (that I think Doug is as well) is: - How many FreeBSD users are developers/performance/test engineers who care about this stuff being compiled into the base system? Don't know. I haven't seen a statistically meaningful poll of the FreeBSD user base on which to draw an answer. I suspect that neither you nor Doug have seen such a poll. Oh please. It doesn't take a poll to know that the overwhelming majority of FreeBSD installs are servers or end-user systems. Well, let's take it to a logical conclusion. What other knobs should default to off? WITHOUT_TOOLCHAIN may be appropriate for the segment of the user base who simply want a server. Clearly, end-users, who do not need profiled libraries, do not do software development so this knob seems appropriate. Well, if these end-users aren't doing software development, we might as well set WITHOUT_MAKE. My experience with 'common users' and reading through freebsd-questions suggests that manpages are useless, so please set WITHOUT_MAN. And since we aren't building manpages, we might as well set WITHOUT_GROFF. There, the system is neutered for the convenience of our end-users. Neither the time to build profiled libraries nor the diskspace used is significant. Great, so why is it such a problem for you to build them? It is not a problem because the libraries are built by default. :-) Of course, there is the converse. Why is it a problem for you to turn off building profiled libaries? -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tuesday, December 20, 2011 5:05:49 am David Chisnall wrote: On 20 Dec 2011, at 06:20, Bruce Evans wrote: Don't be silly. Building profiled libraries takes as much as 1 minute. Many would not want to wait that long (if they noticed how long it takes). This is not 1994 when building of profiling libraries was left in because it only took an extra hour or or so. One of the platforms I use has an 800MHz ARM processor. Building LLVM (even a release build with asserts disabled and with all of the cross-compile targets disabled) is an overnight job. On my main laptop, a release build of LLVM takes about 5 minutes. Please don't assume that just because fast computers exist that they are the only things people are using. A lot of the more interesting platforms these days are significantly slower. And I doubt you do a build with a stock /etc/src.conf on such hardware either. The defaults for src.conf should be for the common case, and in the common case profiled library builds are in the noise. I do add WITHOUT_PROFILE to many of my machines in /etc/src.conf, but I still think they should be enabled by default. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 2:18 AM, Andriy Gapon a...@freebsd.org wrote: on 20/12/2011 12:05 David Chisnall said the following: On 20 Dec 2011, at 06:20, Bruce Evans wrote: Don't be silly. Building profiled libraries takes as much as 1 minute. Many would not want to wait that long (if they noticed how long it takes). This is not 1994 when building of profiling libraries was left in because it only took an extra hour or or so. One of the platforms I use has an 800MHz ARM processor. Building LLVM (even a release build with asserts disabled and with all of the cross-compile targets disabled) is an overnight job. On my main laptop, a release build of LLVM takes about 5 minutes. Please don't assume that just because fast computers exist that they are the only things people are using. A lot of the more interesting platforms these days are significantly slower. I wonder if all the software that runs on the embedded stuff or mobile phones is built on the said hardware. world doesn't need to be built on the hardware, but ports still do. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: The assumption (that isn't clearly stated) is that I am building things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On those platforms building superfluous things still do matter (in particular because cross-building some things still isn't doable 100% of the time, but also because flash, some platter media, etc is slow). But I suppose I digress... When is cross building not doable? Please, give examples, not fud. Warner ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tuesday, December 20, 2011 11:26:11 am Garrett Cooper wrote: On Tue, Dec 20, 2011 at 2:18 AM, Andriy Gapon a...@freebsd.org wrote: on 20/12/2011 12:05 David Chisnall said the following: On 20 Dec 2011, at 06:20, Bruce Evans wrote: Don't be silly. Building profiled libraries takes as much as 1 minute. Many would not want to wait that long (if they noticed how long it takes). This is not 1994 when building of profiling libraries was left in because it only took an extra hour or or so. One of the platforms I use has an 800MHz ARM processor. Building LLVM (even a release build with asserts disabled and with all of the cross- compile targets disabled) is an overnight job. On my main laptop, a release build of LLVM takes about 5 minutes. Please don't assume that just because fast computers exist that they are the only things people are using. A lot of the more interesting platforms these days are significantly slower. I wonder if all the software that runs on the embedded stuff or mobile phones is built on the said hardware. world doesn't need to be built on the hardware, but ports still do. And the discussion here is about profiled libraries built as part of world, not about ports. :) -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh i...@bsdimp.com wrote: On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: The assumption (that isn't clearly stated) is that I am building things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On those platforms building superfluous things still do matter (in particular because cross-building some things still isn't doable 100% of the time, but also because flash, some platter media, etc is slow). But I suppose I digress... When is cross building not doable? Please, give examples, not fud. ports. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 11:21 AM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh i...@bsdimp.com wrote: On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: The assumption (that isn't clearly stated) is that I am building things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On those platforms building superfluous things still do matter (in particular because cross-building some things still isn't doable 100% of the time, but also because flash, some platter media, etc is slow). But I suppose I digress... When is cross building not doable? Please, give examples, not fud. ports. Of course, now that I mention it, that's less relevant to this particular discussion. Please ignore above fud if you have access to fast Intel hardware. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Dec 20, 2011, at 12:21 PM, Garrett Cooper wrote: On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh i...@bsdimp.com wrote: On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: The assumption (that isn't clearly stated) is that I am building things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On those platforms building superfluous things still do matter (in particular because cross-building some things still isn't doable 100% of the time, but also because flash, some platter media, etc is slow). But I suppose I digress... When is cross building not doable? Please, give examples, not fud. ports. Which affects profiled libraries how? Warner ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 11:36 AM, Warner Losh i...@bsdimp.com wrote: On Dec 20, 2011, at 12:21 PM, Garrett Cooper wrote: On Tue, Dec 20, 2011 at 9:40 AM, Warner Losh i...@bsdimp.com wrote: On Dec 20, 2011, at 2:21 AM, Garrett Cooper wrote: The assumption (that isn't clearly stated) is that I am building things on suped up x86 hardware, not arm CPUs, Intel Atoms, etc. On those platforms building superfluous things still do matter (in particular because cross-building some things still isn't doable 100% of the time, but also because flash, some platter media, etc is slow). But I suppose I digress... When is cross building not doable? Please, give examples, not fud. ports. Which affects profiled libraries how? Please see later comment :/. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On 12/20/2011 06:08, John Baldwin wrote: The defaults for src.conf should be for the common case Agreed. The problem we seem to be missing here is that developers are not even statistically significant in measuring the common case. -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On 12/20/2011 18:29, Ben Kaduk wrote: 2011/12/20 Doug Barton do...@freebsd.org: On 12/20/2011 06:08, John Baldwin wrote: The defaults for src.conf should be for the common case Agreed. The problem we seem to be missing here is that developers are not even statistically significant in measuring the common case. The common case of what, though? People using src.conf, or people rebuilding world, or just people using FreeBSD? The latter of course. The overwhelming majority of FreeBSD users will never use profiled libs, and in fact don't even know what they are. It's just useless space being taken up on every install. The defaults should be sensible for our users. The people who actually need to use profiled libs intersects perfectly with the set of people who know how to enable the knob in src.conf. Disabling this by default is a total no-brainer. The fact that it's generated such vehement objection by a miniscule percentage of our user base (read, the developers who still use them) is clearly indicative of a much larger problem. I think Warner summed it up best: The needs of the many? Please. The battle between the forces who see FreeBSD primarily as a hobby project (We're the developers, we do what we like because we like it.) vs. those who'd like to move things in a direction that's more focused on the unwashed masses who actually use the thing, has been going on for a long time. This issue is a good example. Doug (and a sad one) -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 06:45:07PM -0800, Doug Barton wrote: On 12/20/2011 18:29, Ben Kaduk wrote: 2011/12/20 Doug Barton do...@freebsd.org: On 12/20/2011 06:08, John Baldwin wrote: The defaults for src.conf should be for the common case Agreed. The problem we seem to be missing here is that developers are not even statistically significant in measuring the common case. The common case of what, though? People using src.conf, or people rebuilding world, or just people using FreeBSD? The latter of course. The overwhelming majority of FreeBSD users will never use profiled libs, and in fact don't even know what they are. It's just useless space being taken up on every install. The defaults should be sensible for our users. OK, Doug, we get it! You don't like profiled libraries. You don't use them, and by extension the 'common user' does not use them. -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tue, Dec 20, 2011 at 8:55 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Tue, Dec 20, 2011 at 06:45:07PM -0800, Doug Barton wrote: On 12/20/2011 18:29, Ben Kaduk wrote: 2011/12/20 Doug Barton do...@freebsd.org: On 12/20/2011 06:08, John Baldwin wrote: The defaults for src.conf should be for the common case Agreed. The problem we seem to be missing here is that developers are not even statistically significant in measuring the common case. The common case of what, though? People using src.conf, or people rebuilding world, or just people using FreeBSD? The latter of course. The overwhelming majority of FreeBSD users will never use profiled libs, and in fact don't even know what they are. It's just useless space being taken up on every install. The defaults should be sensible for our users. OK, Doug, we get it! You don't like profiled libraries. You don't use them, and by extension the 'common user' does not use them. The point that I was trying to drive home (that I think Doug is as well) is: - How many FreeBSD users are developers/performance/test engineers who care about this stuff being compiled into the base system? - How many developers use gprof / profiled libraries? - How many developers reroll their world by turning on WITH_PROFILE ? - How often do you use gprof to profile binaries? Smart defaults and better tuning are what we ultimately should be striving for, because again, WITH_PROFILE is a developer and not a end-user / administrator convenience. Those are the individuals we should be tailoring FreeBSD for -- not developers. Thanks, -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
[[ I know it is a bit late here ]] On Nov 29, 2011, at 1:50 PM, Doug Barton wrote: On 11/29/2011 12:47, Gábor Kövesdán wrote: On 2011.11.29. 20:46, Max Khon wrote: Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf I think it was useful. Profiling is useful for developing any piece of software that builds on libc or other common libs, even for software that is not directly related to FreeBSD. I think it should be reverted. Since we ask users to read -current, it would be useful if our developers did too. :) But that's not the place to discuss this... It should have gone through arch@ not current@ As Max pointed out in his message about this, the profiled libs are only really useful to a tiny percentage of developers. If you need them, twist the knob. Building them should be off by default. I can't profile my programs effectively without them. Am I now forced to build profile libs with a full FreeBSD to get them? Seems like a big step backwards. Warner ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Nov 29, 2011, at 1:53 PM, Garrett Cooper wrote: 2011/11/29 Doug Barton do...@freebsd.org: On 11/29/2011 12:47, Gábor Kövesdán wrote: On 2011.11.29. 20:46, Max Khon wrote: Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf I think it was useful. Profiling is useful for developing any piece of software that builds on libc or other common libs, even for software that is not directly related to FreeBSD. I think it should be reverted. Since we ask users to read -current, it would be useful if our developers did too. :) As Max pointed out in his message about this, the profiled libs are only really useful to a tiny percentage of developers. If you need them, twist the knob. Building them should be off by default. +1. The needs of the many outweigh the needs of the few. As suggested elsewhere, I think it would also be a good idea to enable it in tinderbox builds. -1. The needs of the many? Please. Let's break a useful feature because some people don't understand it and are impatient? That's lame. Enabling it only on tinderbox builds will ensure more accidental breakage. Warner ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On 19 Dec 2011, at 19:52, Warner Losh wrote: -1. The needs of the many? Please. Let's break a useful feature because some people don't understand it and are impatient? That's lame. How useful is gprof-based profiling these days? Now that we have the DTrace pid provider, don't we have access to much more fine-grained profiling information without the need for shipping two versions of every library? David___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Mon, Dec 19, 2011 at 08:09:32PM +, David Chisnall wrote: On 19 Dec 2011, at 19:52, Warner Losh wrote: -1. The needs of the many? Please. Let's break a useful feature because some people don't understand it and are impatient? That's lame. How useful is gprof-based profiling these days? Now that we have the DTrace pid provider, don't we have access to much more fine-grained profiling information without the need for shipping two versions of every library? It is quite uesful given that for the last 20 or so years, I can do cc -o z -pg a.c -lm_p ./z gprof -b -l ./z z.gmon | more % cumulative self self total time seconds secondscalls ms/call ms/call name 72.1 0.91 0.910 100.00% _mcount [1] 11.1 1.05 0.14 8388608 0.00 0.00 sinf [4] 8.2 1.16 0.10 8388608 0.00 0.00 nextafterf [5] 4.6 1.21 0.060 100.00% .mcount (9) to ge the information I want. dtrace(1M) does not seem to contain an example that gives the equivalent information. In fact, the manpage contains no examples, only the statement: See the Solaris Dynamic Tracing Guide for detailed examples of how to use the dtrace utility to perform these tasks. which, of course, is not very useful given that I do not have a Solaris Dynamic Tracing Guide. -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Mon, Dec 19, 2011 at 12:41:29PM -0800, Steve Kargl wrote: On Mon, Dec 19, 2011 at 08:09:32PM +, David Chisnall wrote: On 19 Dec 2011, at 19:52, Warner Losh wrote: -1. The needs of the many? Please. Let's break a useful feature because some people don't understand it and are impatient? That's lame. How useful is gprof-based profiling these days? Now that we have the DTrace pid provider, don't we have access to much more fine-grained profiling information without the need for shipping two versions of every library? It is quite uesful given that for the last 20 or so years, I can do cc -o z -pg a.c -lm_p ./z gprof -b -l ./z z.gmon | more % cumulative self self total time seconds secondscalls ms/call ms/call name 72.1 0.91 0.910 100.00% _mcount [1] 11.1 1.05 0.14 8388608 0.00 0.00 sinf [4] 8.2 1.16 0.10 8388608 0.00 0.00 nextafterf [5] 4.6 1.21 0.060 100.00% .mcount (9) to ge the information I want. I'd tend to agree that we should leave it on at least in HEAD. dtrace(1M) does not seem to contain an example that gives the equivalent information. In fact, the manpage contains no examples, only the statement: See the Solaris Dynamic Tracing Guide for detailed examples of how to use the dtrace utility to perform these tasks. which, of course, is not very useful given that I do not have a Solaris Dynamic Tracing Guide. http://docs.oracle.com/cd/E19253-01/817-6223/ is it and the first hit in google... -- Brooks pgp4rwgbPgBdL.pgp Description: PGP signature
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Mon, Dec 19, 2011 at 05:04:43PM -0600, Brooks Davis wrote: On Mon, Dec 19, 2011 at 12:41:29PM -0800, Steve Kargl wrote: On Mon, Dec 19, 2011 at 08:09:32PM +, David Chisnall wrote: On 19 Dec 2011, at 19:52, Warner Losh wrote: -1. The needs of the many? Please. Let's break a useful feature because some people don't understand it and are impatient? That's lame. How useful is gprof-based profiling these days? Now that we have the DTrace pid provider, don't we have access to much more fine-grained profiling information without the need for shipping two versions of every library? It is quite uesful given that for the last 20 or so years, I can do cc -o z -pg a.c -lm_p ./z gprof -b -l ./z z.gmon | more % cumulative self self total time seconds secondscalls ms/call ms/call name 72.1 0.91 0.910 100.00% _mcount [1] 11.1 1.05 0.14 8388608 0.00 0.00 sinf [4] 8.2 1.16 0.10 8388608 0.00 0.00 nextafterf [5] 4.6 1.21 0.060 100.00% .mcount (9) to ge the information I want. I'd tend to agree that we should leave it on at least in HEAD. I think it should be the default on all branches. It adds about 28 MB to /usr/lib and 10 minutes to buildworld on my x86_64 systems, ie., it is in the noise. dtrace(1M) does not seem to contain an example that gives the equivalent information. In fact, the manpage contains no examples, only the statement: See the Solaris Dynamic Tracing Guide for detailed examples of how to use the dtrace utility to perform these tasks. which, of course, is not very useful given that I do not have a Solaris Dynamic Tracing Guide. http://docs.oracle.com/cd/E19253-01/817-6223/ is it and the first hit in google... Which isn't very useful if the system that I'm working on has no or very limit internet access. A quick scan of Ch. 19, 'profile Provider' does not give anything that looks remotely similar to the above 3 command lines. Ch. 33 'User Process Tracing' isn't any better. Telling a users that getting an execution profile for her code can be done by first learning the D programming language and then reading a 41 Chapter document available on the web isn't too user friendly. And, if I read Chapter 26 of the FreeBSD Handbook correctly: 1) dtrace is experimental 2) one needs to build a kernel with the KDTRACE_HOOKS, DDB_CTF, and possibly KDTRACE_FRAME. 3) one needs to 'kldload dtraceall' module, which is a showstopper for anyone who builds his kernel with 'makeoptions NO_MODULES' -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
John, On Wed, Nov 30, 2011 at 3:36 AM, John Baldwin j...@freebsd.org wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Hmm, was discussed anywhere? (I haven't seen it if so, but am a bit behind on a few lists from last week still.) It was discussed in -current. Probably should have been discussed somewhere else. Also, it seems you are hacking on several build-related things currently, is there a larger project you are working on to reduce build world times or some such? Yes, I want to reduce build world times. Max ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Wednesday, November 30, 2011 9:35:01 am Max Khon wrote: John, On Wed, Nov 30, 2011 at 3:36 AM, John Baldwin j...@freebsd.org wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Hmm, was discussed anywhere? (I haven't seen it if so, but am a bit behind on a few lists from last week still.) It was discussed in -current. Probably should have been discussed somewhere else. Nah, you were fine. I was just behind on -current. Also, it seems you are hacking on several build-related things currently, is there a larger project you are working on to reduce build world times or some such? Yes, I want to reduce build world times. Ok, can you maybe send a more high-level e-mail of the other things you have pending to current@ perhaps? (If you have more stuff beyond this.) The thread I saw on current@ only covered WITHOUT_PROFILE but didn't cover the CTF changes or anything else, etc. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On Tuesday, November 29, 2011 2:46:17 pm Max Khon wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Hmm, was discussed anywhere? (I haven't seen it if so, but am a bit behind on a few lists from last week still.) Also, it seems you are hacking on several build-related things currently, is there a larger project you are working on to reduce build world times or some such? -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On 2011.11.29. 20:46, Max Khon wrote: Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf I think it was useful. Profiling is useful for developing any piece of software that builds on libc or other common libs, even for software that is not directly related to FreeBSD. I think it should be reverted. Gabor ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
On 11/29/2011 12:47, Gábor Kövesdán wrote: On 2011.11.29. 20:46, Max Khon wrote: Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf I think it was useful. Profiling is useful for developing any piece of software that builds on libc or other common libs, even for software that is not directly related to FreeBSD. I think it should be reverted. Since we ask users to read -current, it would be useful if our developers did too. :) As Max pointed out in his message about this, the profiled libs are only really useful to a tiny percentage of developers. If you need them, twist the knob. Building them should be off by default. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228143 - in head: . share/mk tools/build/options
2011/11/29 Doug Barton do...@freebsd.org: On 11/29/2011 12:47, Gábor Kövesdán wrote: On 2011.11.29. 20:46, Max Khon wrote: Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf I think it was useful. Profiling is useful for developing any piece of software that builds on libc or other common libs, even for software that is not directly related to FreeBSD. I think it should be reverted. Since we ask users to read -current, it would be useful if our developers did too. :) As Max pointed out in his message about this, the profiled libs are only really useful to a tiny percentage of developers. If you need them, twist the knob. Building them should be off by default. +1. The needs of the many outweigh the needs of the few. As suggested elsewhere, I think it would also be a good idea to enable it in tinderbox builds. -Garrett ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
