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>