Date: Mon, 12 Feb 1996 13:49:19 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: John Birrell <cimaxp1!jb@werple.net.au> Cc: critter.tfs.com!phk@werple.net.au (Poul-Henning Kamp), hackers@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: libc_r and the removal of ccitt and iso Message-ID: <256.824129359@critter.tfs.com> In-Reply-To: Your message of "Mon, 12 Feb 1996 10:17:36 %2B1100." <199602112318.KAA03172@werple.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > Keeping libc_r up-to-date with the libc makefiles is a problem. Additions > > > and deletions to the libc makefiles should be reflected in the libc_r tre e. > > > It would be nice if the *same* makefiles could be used, but I don't know > > > how to do that. 8-( > > > > .include ../libc/Makefile > > Ummm. Where would that drop the object modules? ${.CURDIR} doesn't change. > Would you mind the thread specific treatment of renamed syscalls > (for instance) appearing in libc/Makefile? And the extra sub-directory > for thread functions? And different CFLAGS? I know all this can be done, > but I'd like an opinion as to whether it would be acceptable. Rather that than having two almost identical files... If you look in src/release/Makefile you can see another example of reusing almost identical commands for different targets. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?256.824129359>