It would also be best to avoid copying whole files. It's the whole pass-by-value vs pass-by-reference argument. Copy whole file is a nightmare for maintenance, while #including stuff like cmos layout could break a system being upgraded.
Shouldn't p4dpe/Config and p4dpr/Config contain only the parts that differ? ie:
[jjackson@thunderdome supermicro]$ diff p4dpe/Config p4dpr/Config 58c58 < mainboardinit mainboard/supermicro/p4dpe/pci_clk_reset.inc ---
mainboardinit mainboard/supermicro/p4dpr/pci_clk_reset.inc
66c66 < mainboardinit mainboard/supermicro/p4dpe/select_i2c_spd.inc ---
mainboardinit mainboard/supermicro/p4dpr/select_i2c_spd.inc
74c74 < mainboardinit mainboard/supermicro/p4dpe/mainboard_raminit.inc ---
mainboardinit mainboard/supermicro/p4dpr/mainboard_raminit.inc
94c94 < #object devices.o ---
object devices.o
225c225 < option MAINBOARD_PART_NUMBER=P4DP6 ---
option MAINBOARD_PART_NUMBER=P4DPR
And then #include at start or end p4d/Config_common or some such.
Is there an #include like statement for Config files? You could always make one, or does the order of the entries count here? I've seen OOP guys go nuts about proper code factoring, and aside from being seen as fascist, they have really clean code.
On Tue, 2003-02-04 at 11:51, Ronald G. Minnich wrote:
On 4 Feb 2003, Jeremy Jackson wrote:
Will the shared code/common files still be in p4d/, and be referenced or included by the config/other files in p4d/{pe,pe-g2}? If so it makes perfect sense.
yes, and it works really well.
I'm going to flash the image I created from this scheme and let you know.
For the moment I'll leave it at the p4dpe and p4dep/g2 variant, I want to see if I get any other comments.
Thanks Jeremy!
ron