Re: change behavior of elfos.h slightly

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 02:56 05.05.00, Jeffrey A Law wrote:

>   In message <4.3.2.20000504114434.00e0bdb0@mail.lauterbach.com>you write:
>   > >         LOCAL_LABEL_PREFIX: cause an error if this is not defined,
>   > >         as it is required for correct local labels to be generated.
>   > >
>   > >         ASM_OUTPUT_INTERNAL_LABEL: use LOCAL_LABEL_PREFIX rather
>   > >         than assuming one of ".".
>   > >
>   > >         ASM_GENERATE_INTERNAL_LABEL: Likewise.
>   > >
>   > >The latter two are required in order to be able to use elfos.h on
>   > >e.g. MIPS and Alpha targets (assuming you want those targets to
>   > >continue to use the "$" as their local label prefix).
>   >
>   > I think you are heading in the wrong direction here. Though it might 
> be a
>   > good idea to convert elfos.h to provide a default definition of
>   > LOCAL_LABEL_PREFIX and use it, you will still need to override the
>   > definitions in your target headers, because you can't define anything
>   > before including elfos.h. We want to get rid of the
>   >
>   > #define SOMETHING
>   > #include <someheader1.h>
>   > #undef SOMETHING2
>   > #include <someheader2.h>
>Really?  I wasn't aware of that.
>
>The style that we're trying to wean ports from is having one .h file
>include some other .h file by instead listing them explicitly in the
>desired order in configure.in.

But that is a consequence of the configure based scheme, because you can't 
put #define/#undef into tm.h. So if get rid of the above style, you can 
switch to the configure based scheme easily. That's why I think adding new 
workarounds to a _common_ file like elfos.h is the wrong way to go, because 
in the light of the configure based scheme, it just introduces new 
dependencies on a deprecated behaviour. I wouldn't argue that strict on 
changes in the target directories itself though.

>We're trying to enforce it for new ports and when major reconstruction is
>done for existing ports.  But we haven't forced every port to switch when
>dealing with minor problems.

Hmm, I thought the NetBSD stuff was a major reconstruction like OpenBSD was 
sometime ago, and AFAI remember the OpenBSD maintainer was tweaked quite a 
bit before his patches were accepted :-).

My experience with the newppc-branch let's me think that the extra work is 
really worth the effort. It increases maintainability and readability a lot 
and may even uncover latent bugs.

Franz.