[coreboot] [RFC] More generic targets with C preprocessor token concatenation
Carl-Daniel Hailfinger
c-d.hailfinger.devel.2006 at gmx.net
Fri Feb 13 18:48:49 CET 2009
On 13.02.2009 17:19, ron minnich wrote:
> On Fri, Feb 13, 2009 at 4:30 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>> -struct mainboard_amd_dbm690t_config
>> +struct MAINBOARD_PREFIX##_config
>>
>
> Here is the problem: now I don't know the name of that structure when
> I browse it; and, once again, this kind of trickery can trick me, but
> it is also unfriendly to source code analysis tools, which don't
> always pick these subtleties up. What happens with doxygen? What do
> the data structure graphs look like?
>
Point taken. I had assumed that kscope and doxygen would be able to
understand this.
> I realize this sort of thing is become more and more accepted in the
> GNU universe (just look at glibc!), so call me old-fashioned, but I
> feel a structure name should be a structure name, such that people
> don't need to indirect (i.e. grep) to go find out what it really is. I
> haven't found this kind of batch rename to be a huge issue,
> personally.
>
Since this was the first target I wanted to clone, I was surprised by
the amount of search and replace I had to do.
> I'm afraid I don't like the patch. :-)
>
> I'd like us to optimize, if anything, for code that is amenable to
> computer-assisted analysis. I was quite amazed to find out just how
> much (once again) e.g. glibc frustrates tools designed to analyze
> programs. We should be careful about going that route.
>
Can these programs deal with different structs definitions having the
same name, but living in different mainboard dirs?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
More information about the coreboot
mailing list