Re: recent bsd.lib.mk changes
On Fri, Jun 21, 2002 at 07:11:16PM -0400, Mikhail Teterin wrote: On Friday 21 June 2002 06:02 pm, David O'Brien wrote: = On Fri, Jun 21, 2002 at 05:46:17PM -0400, Mikhail Teterin wrote: = Why can't we have some way to explicitly list what is and what is not = needed? = = Feel free to send a patch adding ONLYSHAREDLIBS. INTERNALLIB in no = logical way I can think of would lead someone to think that only shared = libs should be built and they should be installed. Here I agree completely. I have always been puzzled by the naming of this knob. But it was the only way to achieve the goal. It is now a different knob entirely -- but under the same name, which is quite confusing. I am thinking, however, of something explicit like: WANT_SHARED_LIB ?= yes WANT_STATIC_LIB ?= yes WANT_PIC_LIB?= yes with the existing NOPROFILE and others to remain as compatibility interfaces for a while, for example: .ifndef WANT_PIC_LIB .ifndef NOPROFILE WANT_PIC_LIB = yes .else WANT_PIC_LIB = no .endif .endif The last change broke not only some ports, but who knows how many personal projects, which where doing the Right Thing (IMO) and used the bsd.*.mk The lost functionality should now be available again in revision 1.132. I will not have time to make a patch in a while :-\, however... Any way to determine quickly from inside the Makefile, which version of the bsd.lib.mk is installed? OSVERSION. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg40392/pgp0.pgp Description: PGP signature
recent bsd.lib.mk changes
I guess I missed them, but now some of my ports -- which use bsd.lib.mk -- don't work on -current :-\ and I don't know how to fix them in the backward-compatible way. The ports -- such as devel/tcl-memchan, for example, only want to build and install the shared versions of the libraries. I used to define INTERNALLIB to avoid building and installing the static version, but that is now almost reversed -- only the static will be built and nothing will be installed. Any suggestions? For now, can we have some sort of flag be put into the bsd.lib.mk, so the client makefile can check for API-version? Can the future modifications in the share/mk be, please, tested with ports as well as src builds? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Fri, Jun 21, 2002 at 02:29:33PM -0400, Mikhail Teterin wrote: I used to define INTERNALLIB to avoid building and installing the static version, but that is now almost reversed -- only the static will be built and nothing will be installed. The old INTERNALLIB knob was confusion and not really used. An internal lib is a static lib we create during `make world' because it reduces compile times (ie, code that is shared). I can think of very few reasons to build a .so, but not a .a. Some people do like to build static binaries. Can the future modifications in the share/mk be, please, tested with ports as well as src builds? Thanks! src/share/mk is for /usr/src. If /usr/ports can use the bits, that is nice. If not ports/Mk/bsd.FOO.mk should be created and used. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Friday 21 June 2002 04:28 pm, David O'Brien wrote: = On Fri, Jun 21, 2002 at 02:29:33PM -0400, Mikhail Teterin wrote: = I used to define INTERNALLIB to avoid building and installing the = static version, but that is now almost reversed -- only the static = will be built and nothing will be installed. = = The old INTERNALLIB knob was confusion and not really used. An = internal lib is a static lib we create during `make world' because it = reduces compile times (ie, code that is shared). = = I can think of very few reasons to build a .so, but not a .a. Some = people do like to build static binaries. And some people are the opposite. However, for loadable (as in dlopen(3)) plugins, suchs Tcl modules the static libraries are useless at best. Why can't we have some way to explicitly list what is and what is not needed? = Can the future modifications in the share/mk be, please, tested with = ports as well as src builds? Thanks! = = src/share/mk is for /usr/src. If /usr/ports can use the bits, that is = nice. If not ports/Mk/bsd.FOO.mk should be created and used. By this logic, we don't need to install the bsd.*.mk files at all... I, however, disagree. I think they are a great development tool, and have served pretty good so far -- until the very recent and unfortunately incompatible modifications. Note, that they are not even called freebsd.*.mk -- to me, the names implies they are (more or less) consistens among all of the BSDs :-) -- ëÁË, ÷Ù ÒÁÚ×Å ÂÅÚ ÛÐÁÇÉ ÐÒÉÛÌÉ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Fri, Jun 21, 2002 at 05:46:17PM -0400, Mikhail Teterin wrote: = I can think of very few reasons to build a .so, but not a .a. Some = people do like to build static binaries. And some people are the opposite. However, for loadable (as in dlopen(3)) plugins, suchs Tcl modules the static libraries are useless at best. I said few, not none. Why can't we have some way to explicitly list what is and what is not needed? Feel free to send a patch adding ONLYSHAREDLIBS. INTERNALLIB in no logical way I can think of would lead someone to think that only shared libs should be built and they should be installed. By this logic, we don't need to install the bsd.*.mk files at all... If you want cd /usr/src/bin/foo make all install to work, you need to have the installed in /usr/share/mk. Note, that they are not even called freebsd.*.mk -- to me, the names implies they are (more or less) consistens among all of the BSDs :-) They started life when there was but _1_ BSD and that one was from CSRG @ UCB. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Friday 21 June 2002 06:02 pm, David O'Brien wrote: = On Fri, Jun 21, 2002 at 05:46:17PM -0400, Mikhail Teterin wrote: = Why can't we have some way to explicitly list what is and what is not = needed? = = Feel free to send a patch adding ONLYSHAREDLIBS. INTERNALLIB in no = logical way I can think of would lead someone to think that only shared = libs should be built and they should be installed. Here I agree completely. I have always been puzzled by the naming of this knob. But it was the only way to achieve the goal. It is now a different knob entirely -- but under the same name, which is quite confusing. I am thinking, however, of something explicit like: WANT_SHARED_LIB ?= yes WANT_STATIC_LIB ?= yes WANT_PIC_LIB?= yes with the existing NOPROFILE and others to remain as compatibility interfaces for a while, for example: .ifndef WANT_PIC_LIB .ifndef NOPROFILE WANT_PIC_LIB = yes .else WANT_PIC_LIB = no .endif .endif The last change broke not only some ports, but who knows how many personal projects, which where doing the Right Thing (IMO) and used the bsd.*.mk I will not have time to make a patch in a while :-\, however... Any way to determine quickly from inside the Makefile, which version of the bsd.lib.mk is installed? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
