cvs commit: src Makefile.inc1 src/share/mk Makefile
bsd.endian.mk src/usr.bin/cap_mkdb cap_mkdb.1 cap_mkdb.c
src/share/termcap Makefile src/usr.bin/vgrind Makefile
ru at FreeBSD.org
Sun Feb 27 10:09:30 GMT 2005
On Sat, Feb 26, 2005 at 03:34:23PM -0800, David O'Brien wrote:
> On Sat, Feb 26, 2005 at 11:40:53AM +0200, Ruslan Ermilov wrote:
> > On Fri, Feb 25, 2005 at 03:14:09PM -0800, David O'Brien wrote:
> > > On Tue, Feb 22, 2005 at 11:29:54PM +0000, Ruslan Ermilov wrote:
> > > > ru 2005-02-22 23:29:54 UTC
> > > > FreeBSD src repository
> > > > Modified files:
> > > > . Makefile.inc1
> > > > share/mk Makefile
> > > > usr.bin/cap_mkdb cap_mkdb.1 cap_mkdb.c
> > > > share/termcap Makefile
> > > > usr.bin/vgrind Makefile
> > > > Added files:
> > > > share/mk bsd.endian.mk
> > > > Log:
> > > > Add endianness support to cap_mkdb(1), useful for cross builds.
> > >
> > > Rather than having to create bsd.endian.mk and include it; I'd rather
> > > just have the compiler define __LITTLE_ENDIAN__ or __BIG_ENDIAN__.
> > This is for makefiles having to deal with cross-compiles,
> > not for C code.
> I was thinking you could make cap_mkdb(1) know the desired output format
> w/o needing an option to tell it.
No way. We traditionally created these databases (termcap,
vgrind, *pwd.db, and login.conf.db) in a native byte order.
At the time we build them, MACHINE_ARCH is set to TARGET_ARCH
already, so the only way for cap_mkdb(8) to know it should
build the little-endian hash database for i386 on sparc64
is to explicitly pass it the option.
Besides, I'm looking carefully at what NetBSD did to address
these issues, and this is exactly what they have done.
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20050227/ba958919/attachment.bin
More information about the cvs-all