linux-mips-fnet
[Top] [All Lists]

RE: CVS Update@oss.sgi.com: linux

To: Klaus Naumann <spock@mgnet.de>
Subject: RE: CVS Update@oss.sgi.com: linux
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Date: Wed, 24 May 2000 18:50:09 +0200 (CEST)
Cc: Linux MIPS <linux-mips@fnet.fr>, SGI Linux <linux@cthulhu.engr.sgi.com>
In-reply-to: <20000524012413.A5507@spock>
Organization: none
Reply-to: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Sender: harry@franz.no.dom
On 23-May-00 Klaus Naumann wrote:
[offset.h problems with my recent CVS changes snipped]

> Well, unfortunately this doesn't fix the problem.
> At least not for me. I get the same error I 
> stated a mail ago - offset.h is generated after 
> the use in main.c .

Ok, trying to fix that I added a fastdep rule to arch/mips/tools/Makefile only 
to
find myself in a catch 22 situation. offset.c includes asm/ptrace.h which, in
turn, includes asm/offset.h, i.e. you have to have offset.h to create offset.h 
:-o

Without heavily messing around with several header files, which may have an
impact on non-MIPS platforms as well, I see no easy solution for that. Adding an
empty offset.h, on the other hand, and leaving the .cvsignore in place should at
least partially do what I want. Any objections?

And now for something completly different. Why the hell did I mess around with
that?

Well, if something in the kernel is changed which affects offset.h then
generating a diff against a fresh CVS copy will contain those differences. That
annoyed me because, personally, I find this disturbing when reviewing those 
diffs.
Nobody really needs that anyway, at least that's what I thought, because 
offset.h
is generated automatically.

The suggestion I made above would not solve that but at least avoids that those
changes creep into the CVS.

-- 
Regards,
Harald

<Prev in Thread] Current Thread [Next in Thread>