tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: MKPRIVATELIB broken?



On Fri, May 30, 2008 at 04:37:56PM -0400, Thor Lancelot Simon wrote:
  | I have a local tree with BSD-style Makefiles for php5.  It builds each
  | module of php as a library and does MKPRIVATELIB=yes in the Makefile -- for
  | example, the Makefile for zend
  | 
  | .include "../Makefile.inc"
  | .PATH: ${PHPDIST}/Zend
  | MKPRIVATELIB=yes
  | LIB=zend
  | [long list of source files omitted]
  | 
  | I find that since updating my NetBSD sources from mid-February to May 23,
  | I get libzend.a and libzend_pic.a in /usr/lib.
  | 
  | This seems completely wrong.  What did I miss?

That control got renamed to LIBISPRIVATE, because MKPRIVATELIB was
badly named (by me).
We generally try to keep "MKfoo" and "USE_foo" as being the prefixes
for user-controllable settings, and "NOfoo" being the override in
a Makefile where a directory won't ever support MKfoo!=no.
There are still some exceptions to this, such as USE_SHLIBDIR

As an aside, for LIBISPRIVATE to work correctly, you should set it
before <bsd.own.mk> is included; the earlier the better.

I have some uncommitted changes for LIBISMODULE which simplifies
the build & install of "foo.so" (instead of "libfoo.so"); I should
shake them out and commit them because they'll be useful in the
near future for some upcoming nsswitch and PAM modules.

You may also find that your build heirarchy is pulling in
your "../Makefile.inc" twice per Makefile; once explicitly
and once via <bsd.lib.mk> including <bsd.init.mk>.
I noticed this recently with src/usr.sbin/amd in NetBSD.
You may want to consider a revised setup similar to that
which I used in external/bsd/openldap/openldap.mk.

My apologies for the minor headache the rename caused;
I didn't expect that there'd be a big userbase of it
outside of the base.


cheers,
Luke.

Attachment: pgpFu9WvuoctR.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index