Hi,
all boards have various variables named mainboard_$VENDOR_$PARTNUMBER_config and similar. If you run diff between related targets, these variables often account for a sizable chunk of the diff. That means for every new target we have to run a search/replace operation even if the file contents (except variable names) do not change.
I think these search/replace operations are an unnecessary complication during porting and should be eliminated because they require a human to deal with the quirks of our build tools.
Below is a patch example which _should_ remove this type problem.
--- src/mainboard/amd/dbm690t/chip.h (revision 3943) +++ src/mainboard/amd/dbm690t/chip.h (working copy) @@ -19,7 +19,7 @@
extern struct chip_operations mainboard_amd_dbm690t_ops;
-struct mainboard_amd_dbm690t_config +struct mainboard_##MAINBOARD_VENDOR##_##MAINBOARD_PART_NUMBER##_config { u32 uma_size; /* How many UMA should be used in memory for TOP. */ };
I wrote "should" because that patch does not work. MAINBOARD_VENDOR and MAINBOARD_PART_NUMBER are defined as strings with double quotes. Concatenating strings with variable names can't work.
To fix this, I need an additional #define with mainboard vendor and part number and that #define should not be a string.
Suggestion: #define MAINBOARD_PREFIX mainboard_amd_dbm690t
Of course, that #define would be generated as a gcc parameter by our config tools (like MAINBOARD_VENDOR).
With that change in the config tools, the patch above would look like this:
--- src/mainboard/amd/dbm690t/chip.h (revision 3943) +++ src/mainboard/amd/dbm690t/chip.h (working copy) @@ -19,7 +19,7 @@
extern struct chip_operations mainboard_amd_dbm690t_ops;
-struct mainboard_amd_dbm690t_config +struct MAINBOARD_PREFIX##_config { u32 uma_size; /* How many UMA should be used in memory for TOP. */ };
What do you think?
Regards, Carl-Daniel