Subject: RE: CVS [email-masked]: linux

From: Harald Koerfgen <[email-masked]>
Date: Wed, 24 May 2000 18:50:09 +0200 (CEST)

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

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 25 May 2000 01:58:43 +0200

> changes creep into the CVS.

A good solution is important now that we have SMP.  Toggling CONFIG_SMP
affects offset.h and not for all variations of make invocations we
actually have the guarantee that offset.h is being rebuilt before using
it.

  Ralf

---

From: Harald Koerfgen <[email-masked]>
Date: Thu, 25 May 2000 19:14:03 +0200 (CEST)

On 24-May-00 Ralf Baechle wrote:
[offset.h]

> actually have the guarantee that offset.h is being rebuilt before using

What about making offset.h to depend on $(TOPDIR)/.config?

This may cause unneccessary rebuilds of objects depending on offset.h after
configuration changes but it forces offset.h to be rebuilt when CONFIG_SMP is
toggled.

For example:
--- Makefile.old        Thu May 25 19:05:08 2000
+++ Makefile    Thu May 25 19:08:48 2000
@@ -18,7 +18,7 @@
 offset.h: offset.s
        sed -n '/^@@@/s///p' $^ >$@
 
-offset.s: offset.c
+offset.s: offset.c $(TOPDIR)/.config
 
 clean:
        rm -f offset.[hs] $(TARGET).new                                         

-- 
Regards,
Harald

---

From: Ulf Carlsson <[email-masked]>
Date: Thu, 25 May 2000 10:19:40 -0700 (PDT)

> configuration changes but it forces offset.h to be rebuilt when CONFIG_SMP is

Would you mind removing the include/asm-$(ARCH)/offset.h from the CVS
repository, I get conflicts and stuff when I update.  I don't see why we need
to have a dummy file there.

Ulf

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 25 May 2000 20:00:21 +0200

> to have a dummy file there.

Conceptually I don't like that either.

  Ralf

---

From: Ulf Carlsson <[email-masked]>
Date: Thu, 25 May 2000 11:02:52 -0700 (PDT)

> > repository, I get conflicts and stuff when I update.  I don't see why we
> > need to have a dummy file there.
> 

I think my solution that I submitted yesterday was pretty good.  If add a rule
that removes include/asm-$(ARCH)/offset.h when you make clean we will be just
fine.  You'll have to make clean when you toggle between SMP and UP, but I
think we can live with that.

Ulf

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 25 May 2000 20:17:49 +0200

> think we can live with that.

The recent change of __SMP__ to CONFIG_SMP almost everywhere in the kernel
was intended to avoid just that.

  Ralf